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

大家好，我是Z哥。

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

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

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

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

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

寫這篇文章的時候正好想起一個段子，分享給大家圖個樂：

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

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

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

SQL注入

跨站腳本攻擊(XSS)

跨站請求偽造(CSRF)

越權(quán)漏洞

/01 SQL注入/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如何防范呢?主要有兩點。

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

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

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

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

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

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

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

如果這些還嫌多，記不住。那么腦子里記住一個詞——「嚴進嚴出」。

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

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

最常見的4種安全問題，你一定得知道如何應對。

SQL注入

跨站腳本攻擊(XSS)

跨站請求偽造(CSRF)

越權(quán)漏洞

對于其他的安全問題，只要時刻帶著「嚴進嚴出」的思想去coding，相信也能杜絕掉大部分的隱患。

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