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

先聲明一下個(gè)人觀點(diǎn)：

1. 應(yīng)用安全工作決不可能都是由應(yīng)用安全工作者完成的，不是全員參與的應(yīng)用安全工作決不可能做出安全性很好的產(chǎn)品。

2. 公司期望所有與應(yīng)用安全有關(guān)的工作均有應(yīng)用安全工作者來完成，那一定是戰(zhàn)略上的輕視、戰(zhàn)術(shù)上的錯(cuò)誤，最終必將以重大安全事故的出現(xiàn)而結(jié)束這場(chǎng)戰(zhàn)爭(zhēng)。

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

【故事一】：XSS的困惑

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

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

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

假如我是黑客，我發(fā)現(xiàn)某公司網(wǎng)站上可以注入JS腳本，于是我就巧妙的構(gòu)造攻擊URL，通過社會(huì)工程學(xué)的方式誘使對(duì)方點(diǎn)擊我的URL，當(dāng)對(duì)方處于登錄狀態(tài)時(shí)，我可以獲取對(duì)方的會(huì)話信息、本地cookie信息等等，我可以做的事你可以想象了…，在這里我是攻擊者，我們的產(chǎn)品用戶是受害者，我們公司是責(zé)任者，你說我們要不要處理這個(gè)問題?

【故事二】：關(guān)于CSRF的那些事

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

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

一個(gè)需要做身份驗(yàn)證的URL，我們?cè)趯?shí)現(xiàn)的時(shí)候已經(jīng)做了嚴(yán)格的身份驗(yàn)證，現(xiàn)在你的要求等于是讓我我們?cè)僮鲆淮紊矸蒡?yàn)證，這不是折騰嗎?換句話問用戶訪問了一個(gè)只有登錄成功才可以訪問的URL，當(dāng)用戶登錄后可以正常訪問，為什么你還說它需要做身份驗(yàn)證?

開發(fā)人員的問題是有效的，且我認(rèn)為是有價(jià)值的，如果你不能給開發(fā)人員解決這個(gè)問題，他們是不能從心底里形成類似問題的防御意識(shí)，相反他們會(huì)形成一種內(nèi)心的抵抗，最終的效果將是可想而知的。于是我又做了一個(gè)場(chǎng)景的虛擬：

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

此例子當(dāng)中攻擊者是我，受害者是那個(gè)開發(fā)人員，責(zé)任者依然是我們產(chǎn)品—服務(wù)的提供者。

【故事三】：身份認(rèn)證與授權(quán)難解之惑

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

開發(fā)人員：只有登錄的用戶才可以訪問myInfo.do，否則會(huì)轉(zhuǎn)到登錄頁面要求用戶登錄。

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

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

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

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

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