本文轉(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ù)泄露等安全事件引起了不小的輿論轟動。
說實話，現(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的聲音越來越小的原因之一吧。
其實排除一些特定框架中的特定安全問題，具有普遍性的安全問題也不少。其中最常見的就屬以下幾種，我覺得我們每一位程序員應(yīng)該都要知道如何盡量避免這些常見問題的發(fā)生。
SQL注入
跨站腳本攻擊(XSS)
跨站請求偽造(CSRF)
越權(quán)漏洞
/01SQL注入/
SQL注入應(yīng)該是最多人知道的一個安全問題。原因是由于SQL語句的編寫是通過字符串拼接進行的，包括參數(shù)。那么一旦用戶輸入的參數(shù)改變了整個語句的含義，執(zhí)行SQL語句的結(jié)果就變得不可預(yù)期了。比如，
SELECT*FROMuserWHEREid=‘1or1=‘1’。加粗部分就是用戶輸入的內(nèi)容。
如果上面的這段SQL語句被執(zhí)行，用戶信息就全部泄露了。
SQL注入還有很多變種，比如故意讓語句執(zhí)行報錯之類，從錯誤信息中獲取重要信息。
如何防范呢?只要避免SQL拼接，使用參數(shù)化的方式執(zhí)行SQL即可。比如上面這個例子，如果@id參數(shù)的數(shù)據(jù)類型是int，那么「or1=‘1」自然無法轉(zhuǎn)換成int類型。
/02跨站腳本攻擊(XSS)/
XSS最常出現(xiàn)在一些內(nèi)容型站點上，因為他主要針對的是根據(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登陸他的賬號了，想想就有點后怕。
如何防范呢?要么就是過濾掉這種html標(biāo)簽，因為大多數(shù)場景純文本就能滿足。如果實在有富文本的需求，可以進行一次轉(zhuǎn)義，作為字符來存儲，避免將html標(biāo)簽直接保存下來。
另外，針對cookie可以設(shè)置一下httponly，這樣的話js就無法獲取cookie信息了。
/03跨站請求偽造(CSRF)/
CSRF就是利用瀏覽器的緩存以及網(wǎng)站的登陸狀態(tài)記憶功能，通過惡意腳本向你剛訪問過的網(wǎng)站發(fā)起請求，讓網(wǎng)站誤認為是你本人在操作。
比如，你剛訪問過某銀行網(wǎng)站，甚至正在另一個標(biāo)簽頁里打開著這個銀行網(wǎng)站。然后此時不小心點又開了一個釣魚網(wǎng)站，頁面里面的腳本發(fā)起向該銀行網(wǎng)站的轉(zhuǎn)帳請求，你的銀行賬戶就莫名其妙少了一筆錢。(當(dāng)然現(xiàn)在的銀行網(wǎng)站都考慮了這個問題)
如何防范呢?作為網(wǎng)站的開發(fā)者，最簡單的方式就是對referer做判斷，看發(fā)起該請求的來源是否可信。當(dāng)然更好的方式是給每一個正常登陸的用戶分配一個token，用戶發(fā)起的每次請求都對這個token做一下有效性驗證。
/04越權(quán)漏洞/
「越權(quán)」顧名思義，就是超越應(yīng)有的權(quán)限。比如，某個電商網(wǎng)站查看訂單信息的url是http://www.dianshang.com/order/10001。這樣的格式，如果我手動把url最后的數(shù)字修改成10002發(fā)起請求，如果服務(wù)端沒有校驗當(dāng)前登陸人的信息，那么這個10002的訂單信息就被越權(quán)獲取了。
如何防范呢?主要有兩點。
做好權(quán)限校驗，不要偷懶。
編號或者id類的數(shù)據(jù)，避免順序增加。還有一個額外的好處是，避免競爭對手猜到你們的真實訂單數(shù)。
其實還有很多安全問題，比如支付漏洞(支付金額未校驗)、上傳攻擊等等。但是處理起來的大體思路上和上面提到的這4個是類似的。
為了便于大家理解以及在編碼時更具安全意識，我給大家提煉了一些思路。
只要是外部輸入的數(shù)據(jù)，一定要做好全面的校驗，確保處理并返回的數(shù)據(jù)是符合預(yù)期的。
代碼的實現(xiàn)盡量減少多余的外部交互。
錯誤處理的時候，一定不要將技術(shù)層面的異常信息拋出到用戶端，特別是堆棧信息。
如果這些還嫌多，記不住。那么腦子里記住一個詞——「嚴(yán)進嚴(yán)出」。
好了，總結(jié)一下。
這篇呢，Z哥提醒廣大程序員一定要在寫代碼的時候有安全意識。因為網(wǎng)絡(luò)安全的重要性會隨著互聯(lián)網(wǎng)的進一步深入到我們的生活變得更加重要。
最常見的4種安全問題，你一定得知道如何應(yīng)對。
SQL注入
跨站腳本攻擊(XSS)
跨站請求偽造(CSRF)
越權(quán)漏洞
對于其他的安全問題，只要時刻帶著「嚴(yán)進嚴(yán)出」的思想去coding，相信也能杜絕掉大部分的隱患。
不知道你有經(jīng)歷過什么驚心動魄的網(wǎng)絡(luò)安全事件嗎?歡迎在評論區(qū)分享你的經(jīng)驗給大家哦。
