SQL 注入所謂SQL 注入，就是通過把SQL 命令插入到Web 表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執(zhí)行惡意的SQL 命令。通過一下的例子更形象的了解SQL 注入：有一個Lo

SQL 注入

所謂SQL 注入，就是通過把SQL 命令插入到Web 表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執(zhí)行惡意的SQL 命令。

通過一下的例子更形象的了解SQL 注入：

有一個Login 畫面，在這個Login 畫面上有兩個文本框分別用來輸入用戶名和密碼，當用戶點了登錄按鈕的時候，會對輸入的用戶名和密碼進行驗證。驗證的SQL 語句如下： select * from student where username='輸入的用戶名' and password='輸入的密碼' 如果能夠檢索到數據，說明驗證通過，否則驗證不通過。

如果用戶在用戶名文本框中輸入 ' or '1' = '1' or '1' = '1，則驗證的SQL 語句變成：

select * from student where username='' or '1' = '1' or '1' = '1' and password=''

如果用戶在密碼文本框中輸入 1' or '1' = '1，則驗證的SQL 語句變成：

select * from student where username='' and password='1' or '1'='1'

以上兩個SQL 語句的where 條件永遠是成立的，所以驗證永遠是有效的。

如果在用戶名文本框中輸入 tom' ; drop table student-- ，則SQL 語句變成：

[sql] view plaincopyprint?

1. select * from student where username='tom' ; drop table student--' and password='' 這樣就變成的兩條SQL 語句，執(zhí)行完查詢操作，接著直接把student 表給刪除了（雙連接符表示注釋）

如何防止SQL 注入：

1. 永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和雙"-" 進行轉換等。

2. 永遠不要使用動態(tài)拼裝sql ，可以使用參數化的sql 或者直接使用存儲過程進行數據查詢存取

3. 永遠不要使用管理員權限的數據庫連接，為每個應用使用單獨的權限有限的數據庫連接

4. 不要把機密信息直接存放，加密或者hash 掉密碼和敏感的信息

5. 應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝

6. 采用一些工具或網絡平臺檢測是否存在SQL 注入

OS 命令注入

OS 命令注入和SQL 注入差不多，只不過SQL 注入是針對數據庫的，而OS 命令注入是針對操作系統(tǒng)的。OS 命令注入即能夠在服務器上執(zhí)行任意命令。

如何防止OS 命令注入：

1. 不要調用外部程序。舉個例子，在UNIX 系統(tǒng)上，有一個叫CGI 的程序，可以執(zhí)行sendmail 命令來發(fā)送郵件。也許你的web 應用程序也有發(fā)送郵件的功能，通過直接調用

CGI 程序發(fā)送郵件非常的簡單，但是不要這樣做，因為在執(zhí)行sendmail 命令的同時，也會混雜進其他OS 命令，正確的做法是使用發(fā)送郵件的library 。

2. 過濾調 、; ，[ ，] ，| ，< ，> ， 之類的符號

3. 設置用戶的權限

XSS 跨站腳本攻擊

XSS 跨站腳本攻擊指攻擊者在網頁中嵌入客戶端腳本(例如JavaScript) ，當用戶瀏覽此網頁時，腳本就會在用戶的瀏覽器上執(zhí)行，從而達到攻擊者的目的，比如獲取用戶的Cookie ，導航到惡意網站，攜帶木馬等。

XSS 攻擊場景有以下兩個方面：

1. Dom-Based XSS 漏洞。攻擊過程如下

Tom 發(fā)現了Victim.com 中的Search.asp 頁面有XSS 漏洞，Search.asp 的代碼如下：

1.

2.

3.

4. Results for

5. ...

6.

7.

Tom 先建立一個網站http://badguy.com，用來接收“偷”來的信息。然后Tom 構造一個惡意的url(如下) ，通過某種方式(郵件，QQ) 發(fā)給Monica

Monica 點擊了這個URL ，嵌入在URL 中的惡意Javascript 代碼就會在Monica 的瀏覽器中執(zhí)行，那么Monica 在victim.com 網站的cookie ，就會被發(fā)送到badguy 網站中，這樣Monica 在victim.com 的信息就被Tom 盜了

2. Stored XSS(存儲式XSS 漏洞) 。該類型是應用廣泛而且有可能影響大Web 服務器自身安全的漏洞，攻擊者將攻擊腳本上傳到Web 服務器上，使得所有訪問該頁面的用戶都面臨信息泄露的可能。 攻擊過程如下

Alex 發(fā)現了網站A 上有一個XSS 漏洞，該漏洞允許將攻擊代碼保存在數據庫中，于是Alex 發(fā)布了一篇文章，文章中嵌入了惡意JavaScript 代碼。其他人如Monica 訪問這片文章的時候，嵌入在文章中的惡意Javascript 代碼就會在Monica 的瀏覽器中執(zhí)行，其會話cookie 或者其他信息將被Alex 盜走

Dom-Based XSS漏洞威脅用戶個體，而存儲式XSS 漏洞所威脅的對象將是大量的用戶。 如何防止XSS 跨站腳本攻擊：

原則：不相信用戶輸入的數據

注意：攻擊代碼不一定在中

1. 將重要的cookie 標記為http only ，這樣的話Javascript 中的document.cookie 語句就不能獲取到cookie 了

2. 只允許用戶輸入我們期望的數據。例如：年齡的textbox 中，只允許用戶輸入數字，而數字之外的字符都過濾掉

3. 對數據進行Html Encode 處理。< 轉化為 <、> 轉化為 >、& 轉化為 &、' 轉化為 '、" 轉化為 "、空格 轉化為

4. 過濾或移除特殊的Html 標簽。例如：）

CSRF 跨站請求偽造

CSRF （XSRF ）盡管聽起來很想XSS 跨站腳本攻擊，但是它于XSS 完全不同。XSS 是利用站點內的信任用戶，而CSRF 則是通過偽裝來自受信任用戶的請求來利用受信任的站點。 與XSS 相比，CSRF 攻擊不大流行和難以防范，所以比XSS 更具危險性。

以下是一個CSRF 的例子

受害者 Bob 在銀行有一筆存款，通過對銀行的網站發(fā)送請求http://bank.example/withdraw?account=bob&amount=1000000&for=bob2可以使 Bob 把 1000000 的存款轉到 bob2 的賬號下。通常情況下，該請求發(fā)送到網站后，服務器會先驗證該請求是否來自一個合法的 session ，并且該 session 的用戶 Bob 已經成功登陸。

黑客 Mallory 自己在該銀行也有賬戶，他知道上文中的 URL 可以把錢進行轉帳操作。Mallory 可以自己發(fā)送一個請求給銀行：http://bank.example/withdraw?account=bob& amount=1000000&for=Mallory。但是這個請求來自 Mallory 而非 Bob ，他不能通過安全認證，因此該請求不會起作用。

這時，Mallory 想到使用 CSRF 的攻擊方式，他先自己做一個網站，在網站中放入如下代碼：。并且通過廣告等誘使 Bob 來訪問他的網站。當 Bob 訪問該網站時，上述 url 就會從 Bob 的瀏覽器發(fā)向銀行，而這個請求會附帶 Bob 瀏覽器中的 cookie 一起發(fā)向銀行服務器。大多數情況下，該請求會失敗，因為他要求 Bob 的認證信息。但是，如果 Bob 當時恰巧剛訪問他的銀行后不久，他的瀏覽器與銀行網站之間的 session 尚未過期，瀏覽器的 cookie 之中含有 Bob 的認證信息。這時，悲劇發(fā)生了，這個 url 請求就會得到響應，錢將從 Bob 的賬號轉移到 Mallory 的賬號，而 Bob 當時毫不知情。等以后 Bob 發(fā)現賬戶錢少了，即使他去銀行查詢日志，他也只能發(fā)現確實有一個來自于他本人的合法請求轉移了資金，沒有任何被攻擊的痕跡。而 Mallory 則可以拿到錢后逍遙法外。

如何防止CSRF 跨站請求偽造：

1. 對于web 站點，將持久化的授權方法（例如cookie 或者HTTP 授權）切換為瞬時的授權方法（在每個form 中提供隱藏field ）。

2. “雙提交”cookie。此方法只工作于Ajax 請求，但它能夠作為無需改變大量form 的全局修正方法。如果某個授權的cookie 在form post 之前正被JavaScript 代碼讀取，那么限制跨域規(guī)則將被應用。什么叫限制跨域規(guī)則呢？限制跨域規(guī)則就是：如果服務器需要在Post 請求體或者URL 中包含授權cookie 的請求，那么這個請求必須來自于受信任的域，因為其它域是不能從信任域讀取cookie 的。上面那個例子的受信任域就是銀行網站的某個域，而Mallory 發(fā)給Bob 的鏈接不是受信任的域。

3. 使用Post 代替Get 。Post 方式不會在web 服務器和代理服務器日志中留下數據尾巴，然而Get 方式卻會留下數據尾巴。

4. 以上三點都是正對web 站點的防御手段，第4點是從用戶的角度的防御手段。通過在瀏覽其它站點前登出站點或者在瀏覽器會話結束后清理瀏覽器的cookie 來防止CSRF 攻擊。

目錄遍歷漏洞

目錄遍歷漏洞在國內外有不同的叫法（信息泄露漏洞、非授權文件包含漏洞、等等）。目錄遍歷漏洞就是在程序中沒有過濾用戶輸入的../和./之類的目錄跳轉符，導致惡意用戶可以通過提交目錄跳轉來遍歷服務器上的任意文件，其危害可想而知。

如何防止目錄遍歷漏洞：

1. 權限控制

2. 對包含了惡意的符號或者空字節(jié)進行拒絕

3. 使用絕對路徑 參數來控制訪問目錄，使其即使是越權或者跨越目錄也是在指定的目錄下

參數篡改

參數值竄改是網絡攻擊的一種形式，其中在URL 中的某些參數或由用戶輸入的網頁形式領域數據都在沒有得到用戶授權的情況下改變了。這導致瀏覽器指向一個不是用戶想去的鏈接、網頁或網站（盡管對隨機觀測者來說它們看上去幾乎一樣）。參數值篡改被犯罪者用來獲取個人或商業(yè)信息。

如何防止參數篡改：

1. 對所有參數值進行驗證

2. 根據session id進行遷移，參數使用服務器端的值

會話劫持

會話劫持就是在一次正常的會話過程當中，攻擊者作為第三方參與到其中，他可以在正常數據包中插入惡意數據，也可以在雙方的會話當中進行監(jiān)聽，甚至可以是代替某一方主機接管會話。

我們可以把會話劫持攻擊分為兩種類型：1）中間人攻擊(Man In The Middle，簡稱MITM) ，

2）注射式攻擊（Injection ）

中間人攻擊：簡而言之，所謂的MITM 攻擊就是通過攔截正常的網絡通信數據，并進行數據篡改和嗅探，而通信的雙方卻毫不知情

注射式攻擊：這種方式的會話劫持比中間人攻擊實現起來簡單一些，它不會改變會話雙方的通訊流，而是在雙方正常的通訊流插入惡意數據

還可以把會話劫持攻擊分為兩種形式：1）被動劫持，2）主動劫持

被動劫持：在后臺監(jiān)視雙方會話的數據流，叢中獲得敏感數據

主動劫持：將會話當中的某一臺主機“踢”下線，然后由攻擊者取代并接管會話，這種攻擊方法危害非常大，攻擊者可以做很多事情

如何防止會話劫持：

1. 限制入網的連接

2. 設置你的網絡拒絕假冒本地地址從互聯網上發(fā)來的數據包

3. 加密也是有幫助的。FTP 和Telnet 協議是最容易受到攻擊的。SSH 是一種很好的替代方法