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

大家好，我是Z哥。

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

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

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

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

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

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

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

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

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

SQL注入

跨站腳本攻擊(XSS)

跨站請求偽造(CSRF)

越權(quán)漏洞

/01 SQL注入/

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

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)容型站點(diǎn)上，因?yàn)樗饕槍Φ氖歉鶕?jù)服務(wù)端數(shù)據(jù)動態(tài)渲染html的頁面。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SQL注入

跨站腳本攻擊(XSS)

跨站請求偽造(CSRF)

越權(quán)漏洞

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

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