本文轉載自微信公眾號「跨界架構師」，作者Zachary。轉載本文請聯(lián)系跨界架構師公眾號。 

大家好，我是Z哥。

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

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

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

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

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

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

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

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

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

SQL注入

跨站腳本攻擊(XSS)

跨站請求偽造(CSRF)

越權漏洞

/01 SQL注入/

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

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

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

SQL注入還有很多變種，比如故意讓語(yǔ)句執行報錯之類(lèi)，從錯誤信息中獲取重要信息。

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

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

XSS最常出現在一些內容型站點(diǎn)上，因為他主要針對的是根據服務(wù)端數據動(dòng)態(tài)渲染html的頁(yè)面。

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

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

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

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

/03 跨站請求偽造(CSRF)/

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

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

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

/04 越權漏洞/

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

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

做好權限校驗，不要偷懶。

編號或者id類(lèi)的數據，避免順序增加。還有一個(gè)額外的好處是，避免競爭對手猜到你們的真實(shí)訂單數。

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

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

只要是外部輸入的數據，一定要做好全面的校驗，確保處理并返回的數據是符合預期的。

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

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

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

好了，總結一下。

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

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

SQL注入

跨站腳本攻擊(XSS)

跨站請求偽造(CSRF)

越權漏洞

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

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