本文轉(zhuǎn)載自微信公眾號(hào)「跨界架構(gòu)師」，作者Zachary。轉(zhuǎn)載本文請(qǐng)聯(lián)系跨界架構(gòu)師公眾號(hào)。 

大家好，我是Z哥。

不知道大家有沒(méi)有發(fā)現(xiàn)。如今，曝光某些知名公司信息泄露的事件頻率越來(lái)越高。與之對(duì)應(yīng)的，網(wǎng)絡(luò)安全問(wèn)題也越來(lái)越受到重視。

從百度指數(shù)摘錄了兩張圖給大家分享下。

可以看到，對(duì)網(wǎng)絡(luò)安全相關(guān)的信息和關(guān)注度在逐漸走高，特別是近幾年的幾次大型數(shù)據(jù)泄露等安全事件引起了不小的輿論轟動(dòng)。

說(shuō)實(shí)話，現(xiàn)在在企業(yè)做CTO風(fēng)險(xiǎn)還是蠻大的，萬(wàn)一所在的企業(yè)出現(xiàn)什么網(wǎng)絡(luò)安全事件，CTO也得承擔(dān)責(zé)任。

雖然說(shuō)我們廣大程序員們不用承擔(dān)責(zé)任，但是一旦經(jīng)你手發(fā)生的安全事件，你自然也會(huì)受到或多或少的牽連。

寫這篇文章的時(shí)候正好想起一個(gè)段子，分享給大家圖個(gè)樂(lè)：

有人問(wèn)一位搞 WEB 安全的人為什么 PHP 是世界上最好的語(yǔ)言，他的回答是 PHP 網(wǎng)站漏洞多，有飯吃。

這可能也是目前PHP的聲音越來(lái)越小的原因之一吧。

其實(shí)排除一些特定框架中的特定安全問(wèn)題，具有普遍性的安全問(wèn)題也不少。其中最常見(jiàn)的就屬以下幾種，我覺(jué)得我們每一位程序員應(yīng)該都要知道如何盡量避免這些常見(jiàn)問(wèn)題的發(fā)生。

SQL注入

跨站腳本攻擊(XSS)

跨站請(qǐng)求偽造(CSRF)

越權(quán)漏洞

/01 SQL注入/

SQL注入應(yīng)該是最多人知道的一個(gè)安全問(wèn)題。原因是由于SQL語(yǔ)句的編寫是通過(guò)字符串拼接進(jìn)行的，包括參數(shù)。那么一旦用戶輸入的參數(shù)改變了整個(gè)語(yǔ)句的含義，執(zhí)行SQL語(yǔ)句的結(jié)果就變得不可預(yù)期了。比如，

SELECT * FROM user WHERE id = ‘1 or 1 = ‘1’ 。加粗部分就是用戶輸入的內(nèi)容。 

如果上面的這段SQL語(yǔ)句被執(zhí)行，用戶信息就全部泄露了。

SQL注入還有很多變種，比如故意讓語(yǔ)句執(zhí)行報(bào)錯(cuò)之類，從錯(cuò)誤信息中獲取重要信息。

如何防范呢?只要避免SQL拼接，使用參數(shù)化的方式執(zhí)行SQL即可。比如上面這個(gè)例子，如果@id參數(shù)的數(shù)據(jù)類型是int，那么「or 1=‘1」自然無(wú)法轉(zhuǎn)換成int類型。

/02 跨站腳本攻擊(XSS)/

XSS最常出現(xiàn)在一些內(nèi)容型站點(diǎn)上，因?yàn)樗饕槍?duì)的是根據(jù)服務(wù)端數(shù)據(jù)動(dòng)態(tài)渲染html的頁(yè)面。

比如，當(dāng)我在某個(gè)社區(qū)回復(fù)帖子的時(shí)候，故意輸入了「樓主牛逼～」。如果服務(wù)端沒(méi)有做好相應(yīng)的處理，直接把內(nèi)容原封不動(dòng)的存到了數(shù)據(jù)庫(kù)，那么當(dāng)帖子翻到我的回復(fù)所在的樓層，就會(huì)在顯示“樓主牛逼”字樣的同時(shí)出現(xiàn)一個(gè)提示“250”的彈窗。

當(dāng)然，只是彈個(gè)窗沒(méi)啥意思。如果腳本中獲取用戶本地的cookie信息上傳到指定服務(wù)器，那么其他人就可以利用該用戶的cookie登陸他的賬號(hào)了，想想就有點(diǎn)后怕。

如何防范呢?要么就是過(guò)濾掉這種html標(biāo)簽，因?yàn)榇蠖鄶?shù)場(chǎng)景純文本就能滿足。如果實(shí)在有富文本的需求，可以進(jìn)行一次轉(zhuǎn)義，作為字符來(lái)存儲(chǔ)，避免將html標(biāo)簽直接保存下來(lái)。

另外，針對(duì)cookie可以設(shè)置一下httponly，這樣的話js就無(wú)法獲取cookie信息了。

/03 跨站請(qǐng)求偽造(CSRF)/

CSRF就是利用瀏覽器的緩存以及網(wǎng)站的登陸狀態(tài)記憶功能，通過(guò)惡意腳本向你剛訪問(wèn)過(guò)的網(wǎng)站發(fā)起請(qǐng)求，讓網(wǎng)站誤認(rèn)為是你本人在操作。

比如，你剛訪問(wèn)過(guò)某銀行網(wǎng)站，甚至正在另一個(gè)標(biāo)簽頁(yè)里打開(kāi)著這個(gè)銀行網(wǎng)站。然后此時(shí)不小心點(diǎn)又開(kāi)了一個(gè)釣魚(yú)網(wǎng)站，頁(yè)面里面的腳本發(fā)起向該銀行網(wǎng)站的轉(zhuǎn)帳請(qǐng)求，你的銀行賬戶就莫名其妙少了一筆錢。(當(dāng)然現(xiàn)在的銀行網(wǎng)站都考慮了這個(gè)問(wèn)題)

如何防范呢?作為網(wǎng)站的開(kāi)發(fā)者，最簡(jiǎn)單的方式就是對(duì)referer做判斷，看發(fā)起該請(qǐng)求的來(lái)源是否可信。當(dāng)然更好的方式是給每一個(gè)正常登陸的用戶分配一個(gè)token，用戶發(fā)起的每次請(qǐng)求都對(duì)這個(gè)token做一下有效性驗(yàn)證。

/04 越權(quán)漏洞/

「越權(quán)」顧名思義，就是超越應(yīng)有的權(quán)限。比如，某個(gè)電商網(wǎng)站查看訂單信息的url是http://www.dianshang.com/order/10001。這樣的格式，如果我手動(dòng)把url最后的數(shù)字修改成10002發(fā)起請(qǐng)求，如果服務(wù)端沒(méi)有校驗(yàn)當(dāng)前登陸人的信息，那么這個(gè)10002的訂單信息就被越權(quán)獲取了。

如何防范呢?主要有兩點(diǎn)。

做好權(quán)限校驗(yàn)，不要偷懶。

編號(hào)或者id類的數(shù)據(jù)，避免順序增加。還有一個(gè)額外的好處是，避免競(jìng)爭(zhēng)對(duì)手猜到你們的真實(shí)訂單數(shù)。

其實(shí)還有很多安全問(wèn)題，比如支付漏洞(支付金額未校驗(yàn))、上傳攻擊等等。但是處理起來(lái)的大體思路上和上面提到的這4個(gè)是類似的。

為了便于大家理解以及在編碼時(shí)更具安全意識(shí)，我給大家提煉了一些思路。

只要是外部輸入的數(shù)據(jù)，一定要做好全面的校驗(yàn)，確保處理并返回的數(shù)據(jù)是符合預(yù)期的。

代碼的實(shí)現(xiàn)盡量減少多余的外部交互。

錯(cuò)誤處理的時(shí)候，一定不要將技術(shù)層面的異常信息拋出到用戶端，特別是堆棧信息。

如果這些還嫌多，記不住。那么腦子里記住一個(gè)詞——「嚴(yán)進(jìn)嚴(yán)出」。

好了，總結(jié)一下。

這篇呢，Z哥提醒廣大程序員一定要在寫代碼的時(shí)候有安全意識(shí)。因?yàn)榫W(wǎng)絡(luò)安全的重要性會(huì)隨著互聯(lián)網(wǎng)的進(jìn)一步深入到我們的生活變得更加重要。

最常見(jiàn)的4種安全問(wèn)題，你一定得知道如何應(yīng)對(duì)。

SQL注入

跨站腳本攻擊(XSS)

跨站請(qǐng)求偽造(CSRF)

越權(quán)漏洞

對(duì)于其他的安全問(wèn)題，只要時(shí)刻帶著「嚴(yán)進(jìn)嚴(yán)出」的思想去coding，相信也能杜絕掉大部分的隱患。

不知道你有經(jīng)歷過(guò)什么驚心動(dòng)魄的網(wǎng)絡(luò)安全事件嗎?歡迎在評(píng)論區(qū)分享你的經(jīng)驗(yàn)給大家哦。