好久沒寫文章了，之前寫的文章都是實際解決方案的文章往往看起來比較晦澀，本文就說說與我工作有關的故事吧。

先聲明一下個人觀點：

1. 應用安全工作決不可能都是由應用安全工作者完成的，不是全員參與的應用安全工作決不可能做出安全性很好的產品。

2. 公司期望所有與應用安全有關的工作均有應用安全工作者來完成，那一定是戰略上的輕視、戰術上的錯誤，最終必將以重大安全事故的出現而結束這場戰爭。

3. 企業應用安全工作者理應是：安全風險的識別者、解決方案策劃者與設計者及企業工程師安全意識的培訓者，必需得到最高層的直接重視方可得以很好的實施。安全的具體實施理應由普通的工程師完成，規范化滲透測試工作理應由普通的測試工程師來完成。導彈是高科技產品，它的零部件依然是普通的工人來完成的，不要認為應用安全很高深，普通工程師做不了，那是應用安全實現“工藝設計”人員的工作沒做好!

【故事一】：XSS的困惑

在公司的早期，當我演示XSS的問題給我們的開發者與測試人員的時候(e.g. http://www.testfire.net/search.aspx?txtSearch=%3Cscript%3Ealert%281%29%3C%2Fscript%3E)，他們最最困惑的一個問題是：

|誰沒事把自己的頁面注入一串javascript的然后在自己的瀏覽器當中執行?這是漏洞嗎?

這個問題看起來似乎很傻，其實不然，這里蘊涵著一個非常重要的問題：誰是攻擊者、誰是受害者以及誰是責任者的問題，你想過這些問題嗎?若想讓你的公司的員工明白XSS問題的嚴重性必需讓他們從根本上理解問題，方可以得以從心底里接受。于是我就做了一個虛擬的場景：

假如我是黑客，我發現某公司網站上可以注入JS腳本，于是我就巧妙的構造攻擊URL，通過社會工程學的方式誘使對方點擊我的URL，當對方處于登錄狀態時，我可以獲取對方的會話信息、本地cookie信息等等，我可以做的事你可以想象了…，在這里我是攻擊者，我們的產品用戶是受害者，我們公司是責任者，你說我們要不要處理這個問題?

【故事二】：關于CSRF的那些事

先問問讀者：CSRF是漏洞嗎?

在我要求開發人員解決CSRF(CSRF概念可查詢CSRF)問題的時候，我曾經被一個資深開發人員問的目瞪口呆，開發人員的問題是：

一個需要做身份驗證的URL，我們在實現的時候已經做了嚴格的身份驗證，現在你的要求等于是讓我我們再做一次身份驗證，這不是折騰嗎?換句話問用戶訪問了一個只有登錄成功才可以訪問的URL，當用戶登錄后可以正常訪問，為什么你還說它需要做身份驗證?

開發人員的問題是有效的，且我認為是有價值的，如果你不能給開發人員解決這個問題，他們是不能從心底里形成類似問題的防御意識，相反他們會形成一種內心的抵抗，最終的效果將是可想而知的。于是我又做了一個場景的虛擬：

假如我是黑客，你是用戶，我是黑客，當然我同時也是一個用戶，沒有跡象表明我是一個黑客，對于別的用戶來說，我就是一個普通的用戶而已。OK,你登錄了我們的產品，我也登錄了我們的產品，現在我找到了changePasswd.do的API，我發現它并沒有做CSRF防范，但是這個URL是做了嚴格的身份認證檢查的，現在我用changePasswd.do?newPWD=XXXX來構造一個URL，發給你，為了有隱秘性，我可以使用短鏈接的方式發給你，你一眼也看不出來它里面包含了什么，當你點擊之后，它會怎么樣? 開發說：可以正常運行! 我問：為什么不需要登錄、為什么沒要求身份驗證? 開發說：我已經登錄了!我說：這就是CSRF了，你覺得它嚴重嗎?

此例子當中攻擊者是我，受害者是那個開發人員，責任者依然是我們產品—服務的提供者。

【故事三】：身份認證與授權難解之惑

我們要求開發描述清楚你寫的URL或者API的身份認證的要求，比如：myInfo.do，

開發人員：只有登錄的用戶才可以訪問myInfo.do，否則會轉到登錄頁面要求用戶登錄。

我說：這樣寫是不對的，你這樣寫表明只要登錄的用戶都可以訪問myInfo.do了.

開發人員：沒錯啊，登錄的用戶就可以訪問myInfo.do，這有什么問題?

我說：如果我登錄了，但是我訪問的是你的myInfo.do會怎么樣?

開發人員：(…沉思了一會…)，這種情況是可能存在的，但是這是比較偏的情況

我說：我們做安全需要考慮的就是可能存在的安全風險，正確的描述訪問是：只有登錄的用戶才可以訪問他自己的myInfo.do!讀者可能會問：咬文嚼字嗎? 我想說的是：這樣的咬文嚼字必需有，否則后果很嚴重。