WEB安全測試分類及防范測試方法1 Web 應用程序布署環境測試21.1HTTP 請求引發漏洞的測試21.2 操作系統目錄安全性及Web 應用程序布署環境目錄遍歷問題測試22 應用程序測試32.1 SQL 注入漏洞測試32.1.1 SQL注入漏洞攻擊實現原理32.1.2 SQL注入漏洞防范措施42.1.3 SQL注入漏洞檢測方法52.2 表單漏洞測試62.2.1 表單漏洞實現原理62.2.2 表單漏洞防范措施62.2.3 表單漏洞檢測方法62.3 Cookie欺騙漏洞測試82.3.1 Cookie欺騙實現原理82.3.2 Cookie欺騙防范措施82.3.3 Cookie欺騙監測方法92.4 用戶身份驗證測試92.4.1 用戶身份驗證漏洞防范措施92.4.2 用戶身份驗證檢測方法92.5 文件操作漏洞測試92.5.1 文件操作漏洞實現原理92.5.2 文件操作漏洞防范措施102.5.3 文件操作漏洞檢測方法102.6 Session 測試112.6.1 客戶端對服務器端的欺騙攻擊112.6.2直接對服務器端的欺騙攻擊112.6.3 Session漏洞檢測方法122.7 跨網站腳本(XSS)漏洞測試132.7.1 跨網站腳本（XSS）漏洞實現原理132.7.2 跨網站腳本（XSS）漏洞防范措施132.7.3 跨網站腳本（XSS）漏洞測試方法142.8 命令注射漏洞測試142.9 日志文件測試142.10 訪問控制策略測試142.10.1 訪問控制策略測試方法143 數據庫問題測試153.1 數據庫名稱和存放位置安全檢測153.2 數據庫本身的安全檢測153.3 數據使用時的一致性和完整性測試154 容錯測試154.1 容錯方案及方案一致性測試164.2 接口容錯測試164.3 壓力測試161 Web 應用程序布署環境測試用來架構Web 網站的UNIX、LINUX、WINDOWS 等服務器端操作系統和服務器軟件都可能存在漏洞（如前不久被發現的LINUX 系統內核漏洞），這些漏洞都會對Web 應用程序造成安全威脅。因此，在布署Web 應用程序前，應對Web 應用程序的布署環境進行嚴格的測試，檢查一切已知的漏洞，發現新的漏洞，將應用程序環境帶來的安全威脅降底到最低程度。1.1HTTP 請求引發漏洞的測試超長URL 的HTTP 請求，特殊格式字符的HTTP 請求，某些不存在文件的HTTP 請求，COM Internet Services (CIS) RPC over HTTP 漏洞，從而引發拒絕服務，源代碼顯示，站點物理路徑泄露，執行任意命令及命令注入等安全問題。因此，對非常規URL 的HTTP 請求要做全面的測試，以發現這方面的漏洞。測試工作以人工方式為主，并配以Tripwire和AIDE 的完整性檢查工具檢查系統文件，對于發現的漏洞，可采取關閉所有不必要的服務和安裝系統補丁加固系統。另外要保持對最新補丁和安全公告的追蹤，在實驗環境進行測試后正式安裝在布署Web 應用程序的主機上。1.2 操作系統目錄安全性及Web 應用程序布署環境目錄遍歷問題測試目錄權限和目錄安全性直接影響著Web 的安全性。測試中要檢查Web 應用程序布署環境的目錄權限和安全性，不給惡意用戶任何可用的權限。目錄遍歷可能導致用戶從客戶端看到或下載、刪除Web 服務器文件。因此，要測試Web 應用程序及布署環境是否存在目錄遍歷問題；若存在該漏洞，可通過在各級目錄中存放默認文檔或及時升級系統來避免。1.3 系統中危險組件的測試系統中危險組件的存在，會給惡意用戶留下非常危險的“ 后門”。如惡意用戶可利用Windows 系統中存在的FileSystemObject 組件篡改、下載或刪除服務器中的任何文件。因此，若系統中需要使用這些組件，可將這些組件更名；否則將其刪除。1.4 TCP 端口測試開放非必要的端口，會給Web 應用程序帶來安全威脅。因此，在布署Web 應用程序前，要用端口掃描軟件對布署環境進行TCP 端口測試，禁止UDP，只開啟必要的TCP 端口。另外，在系統運行過程中要不斷測試，在服務器端使用lsof 工具(For Unix)或者Inzider 工具(For windows)掃描端口使用情況，必要時從遠程使用Nmap 工具進行異常端口占用檢測。如果發現有未知的進程占用端口，要關閉端口或殺掉進程。2 應用程序測試應用程序中存在的漏洞是影響Web 安全的主要方面，程序員編寫的軟件都可能有漏洞，有些漏洞可能要經過許多年后才會被發現。特別是不斷新加的功能，這些改動，都會帶來安全方面的問題。因此，應用程序測試要伴隨著系統開發、布署和運行的全過程。2.1 SQL 注入漏洞測試2.1.1 SQL注入漏洞攻擊實現原理SQL（Structured Query Language）是一種用來和數據庫交互的語言文本。SQL注入的攻擊原理就是攻擊者通過Web應用程序利用SQL語句或字符串將非法的數據插入到服務器端數據庫中，獲取數據庫的管理用戶權限，然后將數據庫管理用戶權限提升至操作系統管理用戶權限，控制服務器操作系統，獲取重要信息及機密文件。SQL注入利用的是正常的HTTP服務端口，表面上看來和正常的web訪問沒有區別，隱蔽性極強，不易被發現。SQL注入過程如上圖所示，SQL注入攻擊過程分為五個步驟：第一步：判斷Web環境是否可以SQL注入。如果URL僅是對網頁的訪問，不存在SQL注入問題，如：/162414739931.shtml就是普通的網頁訪問。只有對數據庫進行動態查詢的業務才可能存在SQL注入，如：/webhp?id39，其中?id39表示數據庫查詢變量，這種語句會在數據庫中執行，因此可能會給數據庫帶來威脅。第二步：尋找SQL注入點。完成上一步的片斷后，就要尋找可利用的注入漏洞，通過輸入一些特殊語句，可以根據瀏覽器返回信息，判斷數據庫類型，從而構建數據庫查詢語句找到注入點。第三步：猜解用戶名和密碼。數據庫中存放的表名、字段名都是有規律可言的。通過構建特殊數據庫語句在數據庫中依次查找表名、字段名、用戶名和密碼的長度，以及內容。這個猜測過程可以通過網上大量注入工具快速實現，并借助破解網站輕易破譯用戶密碼。第四步：尋找WEB管理后臺入口。通常WEB后臺管理的界面不面向普通用戶開放，要尋找到后臺的登陸路徑，可以利用掃描工具快速搜索到可能的登陸地址，依次進行嘗試，就可以試出管理臺的入口地址。第五步：入侵和破壞。成功登陸后臺管理后，接下來就可以任意進行破壞行為，如篡改網頁、上傳木馬、修改、泄漏用戶信息等，并進一步入侵數據庫服務器。2.1.2 SQL注入漏洞防范措施SQL注入漏洞攻擊的防范方法有很多種，現階段總結起來有以下方法：（1）數據有效性校驗如果一個輸入框只可能包括數字，那么要通過校驗確保用戶輸入的都是數字。如果可以接受字母，那就要檢查是不是存在不可接受的字符，最好的方法是增加字符復雜度自動驗證功能。確保應用程序要檢查以下字符：分號、等號、破折號、括號以及SQL關鍵字。另外限制表單數據輸入和查詢字符串輸入的長度也是一個好方法。如果用戶的登錄名最多只有10個字符，那么不要認可表單中輸入10個以上的字符，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。（2）封裝數據信息對客戶端提交的數據進行封裝，不要將數據直接存入cookie中，方法就是在編程的代碼中，插入session、if、try、else，這樣可以有效地防止攻擊者獲取cookie中的重要信息。（3）去除代碼中的敏感信息將在代碼中存在的用戶名、口令信息等敏感字段刪除，替換成輸入框。如：SQL= select from users where username = adminand password= 1234567 這樣顯然會暴露管理員的用戶名、口令信息。可以將其修改成SQL= select * from users where username= +Txtuser.Text + and userpwd= + Textpwd.Text + ，這樣就安全了很多，入侵者也是不會輕易的就獲取到用戶名、口令信息。（4）替換或刪除單引號使用雙引號替換掉所有用戶輸入的單引號，這個簡單的預防措施將在很大程度上預防SQL注入漏洞攻擊，單引號時常會無法約束插入數據的Value，可能給予輸入者不必要的權限。用雙引號替換掉單引號可以使大部分SQL注入漏洞攻擊失敗。如：“select* from users where username= + admin + and userpwd= + 1234567+ ”顯然會得到與“select * from users where username=admin and password= 1234567”相同的結果。（5）指定錯誤返回頁面攻擊者有時從客戶端嘗試提交有害代碼和攻擊字符串，根據Web Service給出的錯誤提示信息來收集程序及服務器的信息，從而獲取想得到的資料。應在Web Service中指定一個不包含任何信息的錯誤提示頁面。（6）限制SQL字符串連接的配置文件使用SQL變量，因為變量不是可以執行的腳本，即在Web頁面中將連接數據庫的SQL字符串替換成指定的Value，然后將Web.config文件進行加密，拒絕訪問。（7）設置Web目錄的訪問權限將虛擬站點的文件目錄禁止游客用戶（如：Guest用戶等）訪問，將User用戶權限修改成只讀權限，切勿將管理權限的用戶添加到訪問列表。（8）最小服務原則Web服務器應以最小權限進行配置，只提供Web服務，這樣可以有效地阻止系統的危險命令，如ftp、cmd、vbscript等。（9）鑒別信息加密存儲將保存在數據庫users表中的用戶名、口令信息以密文形式保存，也可以對users表進行加密處理，這樣可以大大增加對鑒別信息訪問的安全級別。（10）用戶權限分離應盡可能的禁止或刪除數據庫中sa權限用戶的訪問，對不同的數據庫劃分不同的用戶權限，這樣不同的用戶只能對授權給自己的數據庫執行查詢、插入、更新、刪除操作，就可以防止不同用戶對非授權的數據庫進行訪問。2.1.3 SQL注入漏洞檢測方法SQL注入漏洞攻擊檢測分為入侵前的檢測和入侵后的檢測。入侵前的檢測，可以通過手工方式，也可以使用SQL注入漏洞掃描工具軟件。檢測的目的是為預防SQL注入漏洞攻擊，而對于SQL注入漏洞攻擊后的檢測，主要是針對審計日志的查看，SQL注入漏洞攻擊成功后，會在Web Service和數據庫的審計日志中留下“痕跡”。檢測方法如下：（1）動態SQL檢查動態的SQL語句是一個進行數據庫查詢的強大的工具，但把它和用戶輸入混合在一起就使SQL注入成為了可能。將動態的SQL語句替換成預編譯的SQL或者存儲過程對大多數應用程序是可行的。預編譯的SQL或者存儲過程可以將用戶的輸入作為參數而不是命令來執行，這樣就限制了入侵者的行動。當然，它不適用于存儲過程中利用用戶輸入來生成SQL命令的情況。在這種情況下，用戶輸入的SQL命令仍可能得到執行，數據庫仍然存在SQL注入漏洞攻擊的危險。（2）有效性校驗如果一個輸入框只可能包括數字，那么要通過驗證確保用戶輸入的都是數字。如果可以接受字母，檢查是不是存在不可接受的字符，那就需要設置字符串檢查功能。確保應用程序要檢查以下字符：分號、等號、破折號、括號以及SQL關鍵字。（3）數據表檢查 使用SQL注入漏洞攻擊工具軟件進行SQL注入漏洞攻擊后，都會在數據庫中生成一些臨時表。通過查看數據庫中最近新建的表的結構和內容，可以判斷是否曾經發生過SQL注入漏洞攻擊。（4）審計日志檢查 在Web服務器中如果啟用了審計日志功能，則Web Service審計日志會記錄訪問者的IP地址、訪問時間、訪問文件等信息，SQL注入漏洞攻擊往往會大量訪問某一個頁面文件（存在SQL注入點的動態網頁），審計日志文件會急劇增加，通過查看審計日志文件的大小以及審計日志文件中的內容，可以判斷是否發生過SQL注入漏洞攻擊事件；另外還可以通過查看數據庫審計日志，查詢某個時間段是否有非法的插入、修改、刪除操作。（5）其他 SQL注入漏洞攻擊成功后，入侵者往往會添加特權用戶（如：administrator、root、sa等）、開放非法的遠程服務以及安裝木馬后門程序等，可以通過查看用戶帳戶列表、遠程服務開啟情況、系統最近日期產生的一些文件等信息來判斷是否發生過入侵。SQL 注入攻擊源于英文“SQL Injection Attack”。微軟技術中心從兩個方面對SQL 注入攻擊進行了描述：一是腳本注入式的攻擊；二是惡意用戶輸入用來影響被執行的SQL腳本。Stephen Kost 對這種攻擊形式的描述是“從一個數據庫獲得未經授權的訪問和直接檢索”。SQL 注入就其本質而言，是利用SQL 語法，對應用程序中的漏洞的攻擊。當攻擊者能夠操縱數據，在應用程序中插入一些SQL 語句時，SQL 注入攻擊就發生了。理論上，這種攻擊對于所有基于SQL 語言標準的數據庫軟件都是有效的，包括MS SQL Server，Oracle，DB2，Sybase，MySQL等。特別是現在一些AQL 注入攻擊工具的出現，使得Web應用更易遭到SQL 注入攻擊。原始的手工測試不適用于大型Web 應用程序，可使用N-Stealth、WebInspect、Wikto WebScarab、Nikto 等工具進行掃描，測試系統是否存在SQL 注入的安全漏洞。為防止SQL 注入，程序員編寫代碼時，要對客戶端和服務端進行兩級檢查。檢查數據類型、數據長度和敏感字符的合法性。客戶端檢查可減少網絡流量，降低服務器負荷，將一般誤操作、低等級攻擊與高等級攻擊行為區分開來。對于繞開客戶端檢查的攻擊，提交的數據被直接發往服務端，服務端檢查到的提交異常基本可以認定為惡意攻擊行為所致，就應中止提交信息的處理，進行攻擊備案，并對客戶端給出出錯或警告提示。另外，在構造查詢時，應根據用戶輸入的內容設置參數值來創建參數化查詢，從而避免SQL 注入及由此帶來的安全問題。2.2 表單漏洞測試2.2.1 表單漏洞實現原理表單提交是當前Web應用中的重要內容，用戶可以通過這種方式與服務器進行數據傳遞。在通常情況下，會在提交表單之前在服務器上進行表單數據的驗證，這樣可以節省服務器資源，但同時也為服務器帶來了安全漏洞。表單提交的數據的驗證和服務端數據接收的方法直接影響到Web 的安全。隨著大量的支持參數的“模糊化”（“fuzzing”）、腐朽（corruption）、以及野蠻強制增長工具的出現，使用非校驗輸入進行攻擊造成的安全問題越來越多。因此，表單漏洞測試是Web 安全所必需的。2.2.2 表單漏洞防范措施為防止表單漏洞的攻擊，編程時應有一個中心化的、強大的驗證機制來對所有HTTP 請求的輸入進行驗證，過濾可能危及后臺數據庫的特殊字符、腳本語言和命令。為防止攻擊者繞過客戶端的安全機制，對這些字符的檢測應在Web 服務端實現，采用清除或者強制替換的方法避免服務器端的安全，并且使用MD5 哈希(hash)函數或者時間戳數字簽名技術對客戶端敏感數據必須進行完整性保護。解決這種漏洞的方法為在提交表單頁面進行校驗的同時，在接收表單的處理頁面也進行校驗，這樣即使用戶使用非法方式提交的非法數據通過了頁面驗證也無法通過服務器上的驗證。2.2.3 表單漏洞檢測方法 表單數據提交測試。l 對表單數據提交的測試，主要檢查程序中是否對表單所提交數據的完整性、正確性進行了驗證（如果在頁面部分進行驗證的話），如：查詢條件輸入一些特殊字符，比如“-”，“，”，“”等會使查詢的SQL語句出錯l 檢查程序中是否屏蔽了表單提交的html 語句、VBScript 和Jscript 等客戶端腳本語句l 檢查是否會出現“腳本利用”問題l 檢查程序是否對表單域長度進行了真正的限制l 檢查是否存在重復提交數據的問題l 檢查這些驗證是否在服務器端進行對表單提交數據的測試，可以采用手工和編寫可重復使用的腳本代碼相結合的方法，進行邊界值測試、等價類測試，以及異常類測試。編寫的腳本代碼可以在測試、回歸測試時運行。若在測試中發現數據完整性、正確性驗證只是在客戶端進行，應在服務器端增加對表單提交數據的驗證，防止出現本地提交表單的漏洞。 本地提交表單的漏洞測試。本地提交表單的漏洞容易受到參數篡改的攻擊。這類測試可用手工的方式進行。對于如下用戶注冊頁面：1. 2. functioncheckUser() 3. if(document.getElementById(userName).value=) 4. document.getElementById(button).disabled=true; 5. alert(用戶名不可以為空); 6. returnfalse; 7. else 8. document.getElementById(button).disabled=false; 9. 10. 11. functioncheckPsw() 12. if(document.getElementById(password).value=) 13. document.getElementById(button).disabled=true; 14. alert(密碼不可以為空); 15. returnfalse; 16. else 17. document.getElementById(button).disabled=false; 18. 19. 20. 21. 22. 23. 24. 25. 此頁面中的JavaScript對表單中用戶名和密碼是否為空進行了判斷，如果用戶名或密碼有一者為空時就會將提交按鈕設置為不可用，這樣可以阻止用戶的提交。但是這個頁面的內容可以完全通過查看頁面源代碼的方式看到，用戶可以通過查看源代碼的方式將其中的JavaScript部分去掉，同時將表單action請求指向此頁面原來的地址，然后將修改后的頁面保存為一個靜態HTML頁面，這樣就可以完成一個非法的數據提交。修改之后的頁面代碼如下：1. 2. 3. 4. 5. 如此一個頁面，完全允許用戶提交任何一種數據，包括空的用戶名和密碼。2.3 Cookie欺騙漏洞測試2.3.1 Cookie欺騙實現原理Cookie最先是由Netscape（網景）公司提出的，Netscape官方文檔中對Cookie的定義是這樣的：Cookie是在HTTP協議下，服務器或腳本可以維護客戶工作站上信息的一種方式。Cookie的用途非常廣泛，在網絡中經常可以見到Cookie的身影。它通常被用來辨別用戶身份、進行session跟蹤，最典型的應用就是保存用戶的賬號和密碼用來自動登錄網站和電子商務網站中的“購物車”。Cookie注入簡單來說就是利用Cookie而發起的注入攻擊。從本質上來講，Cookie注入與傳統的SQL注入并無不同，兩者都是針對數據庫的注入，只是表現形式上略有不同罷了。2.3.2 Cookie欺騙防范措施（1）刪除Cookie記錄在IE瀏覽器【工具】【Internet選項】中刪除Cookie，也可借助相應安全軟件來實現。（2）更改Cookie文件的保存位置在【Internet選項】對話框中單擊【設置】按鈕，在設置頁面單擊【移動文件夾】出現如下圖，在其中設置相應保存位置（如F:），即可成功更改Cookie文件的保存位置。 （3）添加防注入代碼2.3.3 Cookie欺騙監測方法如果系統使用了cookie，就要對cookie 的使用情況進行檢測。檢查Cookies 在生存期內能否正常工作而且對這些信息是否加密，是否按預定的時間進行保存，是否存在cookie 可被偽造提交的問題，刷新對Cookie 有什么影響及過期處理等。2.4 用戶身份驗證測試2.4.1 用戶身份驗證漏洞防范措施l 限制用戶名、密碼最大字符數、字符類型l 限制登錄次數，超出允許次數后給出友好提示l 限制用戶權限用戶身份驗證，客戶端提交的密碼需加密，服務端驗證密碼使用MD5，若在測試中發現問題，應及時修改代碼，使用加密碼算法對密碼加密。2.4.2 用戶身份驗證檢測方法l 測試有效和無效的用戶名和密碼，測試是否大小寫敏感，是否有最大字符數的限制規則等。l 測試重試次數的限制，如果登錄失敗的次數超過允許值，應用程序將會做出何種反應 （譬如拒絕此IP地址在短時間內的登錄）。l 測試是否可以利用歷史登錄信息或以前的URL來繞開登錄程序。l 測試執行添加、刪除、修改等動作中是否需要登錄操作，退出系統之后的操作是否仍可繼續等。l 測試用戶密碼是否符合指定要求（字符、長度），如果不符合，對有什么影響，新用戶自己修改密碼后，創建時分配的密碼是否會失效。l 測試用戶賬戶過期后，是否完全、正確的刪除其信息或使其失效。l 是否存在不驗證而直接進入Web 應用系統的問題，是否存在不登錄就可查看非會員頁面和權限問題。用戶身份驗證測試一般使用手工和測試工具相結法的方法，若在測試中發現問題，應及時修改代碼，使用加密碼算法對密碼加密，采用Session 對象進行登錄驗證。2.5 文件操作漏洞測試2.5.1 文件操作漏洞實現原理上存漏洞常見有，文件名檢測漏洞，還有就是文件格式檢查漏洞。 另外還有一個，就是保存文件存在漏洞。這類漏洞，主要是可以讀取用戶傳入路徑名稱，采用不正確的過濾方法，導致惡意用戶，將文件上存到非預期的地方，帶來安全隱患。2.5.2 文件操作漏洞防范措施抓住幾個地方即可，先來分析下，既然用戶要上存文件，而且文件將是多種多樣格式；可能有的文件內容與用戶傳入格式不一致，有的文件內容還夾雜木馬代碼。 那么，我們讓用戶上存文件，跟站點文件做一個分別授權，做隔離。l 讓保存上存目錄獨立開來，目錄權限只讀不能執行這一步從系統設計加以授權，無論你上次什么文件，都不可能執行到。就算我不做任何檢測，你的文件都上存到這里了，也不會對我系統構成安全。（如果有用戶上存一些反動言語的圖片，那另外需要處理的）l 不直接使用服務器傳入值，所有都要進行檢測這類跟我們做一切輸入都是有害原則一樣，對于客戶端傳入的：type, name ，都要進行判斷，不直接使用。對于要生成到某個目錄，某個文件名。文件名最好方法是：自己寫死目錄（不要讀取傳入目錄），文件名，最好自己隨機生成，不讀取用戶文件名。文件擴展名，可以取最右邊”.”后面字符。以上2個方法，剛好從2個方面對上存做了整體約束。方法1：只要保證文件寫對了位置，然后從配置上，對寫入目錄進行權限控制，這個是治本。可以做到，你無論上存什么文件，都讓你沒有權限跳出去可以運行。方法2 ： 保存上存文件名，按照自己指定目錄寫入，并且文件名自己生成的。以上2個方法，一起使用，可以保證文件正確存到地方，然后，權限可以控制。 這里順便說明下， 判斷用戶上存文件是否滿足要求類型，就直接檢查文件擴展名，只要滿足擴展名就讓上存。 反正，做了執行權限限制，你不按要求上存內容，也無妨。 反正，不能執行，也不會有多大危害性的。正確步驟：1.讀取文件名，驗證擴展名是不是在范圍內2.自己定義生成的文件名，目錄，擴展名可以來自文件名擴展名。 其它值，都自己配置，不讀取上存中內容3.將文件 移到新目錄(這個目錄權限設置只讀)2.5.3 文件操作漏洞檢測方法l 測試系統是否允許上傳腳本文件、可執行文件等有可能給系統帶來危害的文件。l 若有下載功能，可供下載的文件是否與系統的程序分別存放，是否存在數據庫文件、包含文件和頁面文件下載的可能。文件操作漏洞測試一般使用手工測試的方法，若發現問題，應及時修改代碼并將可供下載的文件重新布署。2.6 Session 測試2.6.1 客戶端對服務器端的欺騙攻擊 攻擊原理在用戶訪問并登錄了某個網站后，該網站的服務器就會給該用戶機子上分配一個sessionid，此信息是通過客戶機的cookies存放在某一文件夾里面的。session本身并不是長期有效，每一個session在客戶端關閉瀏覽器后sessionid都會自動撤銷，但服務端默認保存20分鐘。正是有這20分鐘的時間，給欺騙帶來了可能。服務器端對不同用戶的識別，只能通過sessionid進行，也就是說網站服務器端是“只認id不認人”，只要id符合，就認為是合法用戶，所以攻擊者只要得到了被攻擊對象的sessionid就可以以被攻擊對象的身份合法登錄，而20分鐘的默認保留值，也使得攻擊者即使在被攻擊對象關閉瀏覽器后依然有一定的時間成功登錄。當前利用此原理進行攻擊的常用手法是利用網站本身的xss漏洞或者是誘騙被攻擊者點擊相應鏈接，以使其隱蔽訪問攻擊者事先假設好的網站并執行惡意代碼，獲取被攻擊者的cookies信息從而得到sessionid。最后用可以修改sessionid的瀏覽器或其它可以提交數據的工具偽裝成被攻擊者的id合法登錄。 防范措施此類攻擊過程較為隱蔽，但也有其局限性。因為session本身有時間限制，特別是用戶在關閉瀏覽器后，留給攻擊者的時間也只有20分鐘。另外，在觸發機制上，盜竊cookies代碼的執行必須是用戶自己觸發，也就是說，用戶什么時候觸發代碼，攻擊者是不知道的，從用戶觸發惡意代碼到session失效，攻擊者只有很短的時間進行非法活動。所以，要對此類攻擊進行防范，客戶端本身應對陌生人給出的超級鏈接保持警惕，特別是對比較長的超鏈接更要小心。每次登錄網站后應該及時利用網站的退出功能退出和清除本機的cookies。另外登錄密碼的設置不要過于簡單，盡量使用字母與數字組合，密碼長度應該在8位以上。網站管理員在開發網站時要注意檢查網站的xss漏洞，要注意session有效期的設置，一般不要把有效期設置太長，這樣即使真的被攻擊也能讓其非法活動時間大大縮短。2.6.2直接對服務器端的欺騙攻擊 攻擊原理與客戶端欺騙不同，此類攻擊是對服務器端的直接欺騙。網站開發者在管理員管理頁面通常都會有session驗證，目的是為了驗證當前登錄者是否為合法用戶。但如果攻擊者能夠在登錄管理頁面前，使用某種手段使得session（”admin”）被賦值（不一定是網站開發者所賦予的值）則驗證代碼則無法攔截此類非法登錄。從而達到了直接欺騙服務器而以管理員身份直接登錄的目的。當前利用此原理進行攻擊的常用手法是都是在取得了某網站域名下的某個webshell進行的。如許多免費空間網站都會在主域名下允許用戶有自己的二級域名，而此域名的目錄又和網站主目錄在同一站點下，這樣就為欺騙攻擊提供了條件。而其它一些網站由于自身的xss等漏洞，使得用戶拿下某個webshell，從而也使欺騙攻擊成為了可能。在具備了欺騙必備條件后，攻擊者還必須知道session驗證的源碼，從而才能編寫惡意代碼繞過系統原有的驗證。當然，如果驗證源碼是上文所列的情況，則攻擊者只需知道session所用變量即可，因為其并沒有給出具體的賦值，只是簡單的驗證是否為空。攻擊者只要賦任意值即可通過此驗證。 防范措施此類攻擊手法也相當隱蔽，危害極大。因為攻擊一旦成功，則攻擊者即可以管理員身份非法登錄。從此類欺騙攻擊的原理我們知道，此攻擊要成功必須具備多個先決條件：獲得該域名下的一個webshell或者攻擊網站與被欺騙網站在同一主站的同一目錄下；被攻擊主站采取了session驗證管理頁面；獲得被攻擊站點的session驗證源碼；知道被攻擊主站的管理頁面地址。所以我們要防范此類攻擊，就只能從幾個限制條件考慮。網站開發者應該盡量避免各種漏洞，站點在使用前應該經過周密而詳盡的測試，從而降低被發現漏洞的可能。對于網站源碼不能輕易泄露，特別是在公開場合。如果是使用公開源碼假設的網站，更要把源碼關鍵部位更改。本攻擊欺騙的關鍵源碼部位即session驗證源碼。2.6.3 Session漏洞檢測方法（1）Session互竄Session互竄即是用戶A的操作被用戶B執行了。驗證Session互竄，其原理還是基于權限控制，如某筆訂單只能是A進行操作，或者只能是A才能看到的頁面，但是B的session竄進來卻能夠獲得A的訂單詳情等。Session互竄方法：多TAB瀏覽器，在兩個TAB頁中都保留的是用戶A的session記錄，然后在其中一個TAB頁執行退出操作，登陸用戶B，此時兩個TAB頁都是B的session，然后在另一個A的頁面執行操作，查看是否能成功。預期結果：有權限控制的操作，B不能執行A頁面的操作，應該報錯，沒有權限控制的操作，B執行了A頁面操作后，數據記錄是B的而不是A的。（2）Session超時基于Session原理，需要驗證系統session是否有超時機制，還需要驗證session超時后功能是否還能繼續走下去。測試方法：1、打開一個頁面，等著10分鐘session超時時間到了，然后對頁面進行操作，查看效果。2、多TAB瀏覽器，在兩個TAB頁中都保留的是用戶A的session記錄，然后在其中一個TAB頁執行退出操作，馬上在另外一個頁面進行要驗證的操作，查看是能繼續到下一步還是到登錄頁面。Session 測試主要檢查Web 應用系統是否有超時的限制，也就是檢查用戶登錄后在一定時間內沒有點擊任何頁面，是否需要重新登錄才能正常使用，檢查超時后能否自動退出，退出之后，瀏覽器回退按鈕是否可以回到登錄頁面。Session 測試一般使用手工測試和工具測試相結合的方法，若發現問題，應及時修改代碼。2.7 跨網站腳本(XSS)漏洞測試2.7.1 跨網站腳本（XSS）漏洞實現原理跨站腳本漏洞（Cross Site Scripting，常簡寫作XSS）是Web應用程序在將數據輸出到網頁的時候存在問題，導致攻擊者可以將構造的惡意數據顯示在頁面的漏洞。因為跨站腳本攻擊都是向網頁內容中寫入一段惡意的腳本或者HTML代碼，故跨站腳本漏洞也被叫做HTML注入漏洞（HTML Injection）。與SQL注入攻擊數據庫服務器的方式不同，跨站腳本漏洞是在客戶端發動造成攻擊，也就是說，利用跨站腳本漏洞注入的惡意代碼是在用戶電腦上的瀏覽器中運行的。2.7.2 跨網站腳本（XSS）漏洞防范措施下列規則旨在防止所有發生在應用程序的XSS攻擊，雖然這些規則不允許任意向HTML文檔放入不可信數據，不過基本上也涵蓋了絕大多數常見的情況。你不需要采用所有規則，很多企業可能會發現第一條和第二條就已經足以滿足需求了。請根據自己的需求選擇規則。（1） 不要在允許位置插入不可信數據第一條規則就是拒絕所有數據，不要將不可信數據放入HTML文檔，除非是下列定義的插槽。這樣做的理由是在理列有解碼規則的HTML中有很多奇怪的context，讓事情變得很復雜，因此沒有理由將不可信數據放在這些context中。（2） 在向HTML元素內容插入不可信數據前對HTML解碼這條規則適用于當你想把不可信數據直接插入HTML正文某處時，這包括內部正常標簽(div、p、b、td等)。大多數網站框架都有HTML解碼的方法且能夠躲開下列字符。但是，這對于其他HTML context是遠遠不夠的，你需要部署其他規則。（3） 在向HTML常見屬性插入不可信數據前進行屬性解碼這條規則是將不可信數據轉化為典型屬性值(如寬度、名稱、值等)，這不能用于復雜屬性(如href、src、style或者其他事件處理程序)。這是及其重要的規則，事件處理器屬性(為HTML JavaScript Data Values)必須遵守該規則。2.7.3 跨網站腳本（XSS）漏洞測試方法對于呈增長趨勢的跨站腳本（XSS）攻擊，可使用內嵌檢測的方式進行處理。使用WebInspect 工具識別所有的假造參數，使用DevInspect 工具通過特定代碼關聯在頁面上發現安全缺陷，對于顯示代碼，采用CSE HTML Validator工具進行測試。若在檢測中發現系統存在跨站腳本(X SS)漏洞，使用輸出數據編碼也就是將任何數據返回給用戶前均采用HTML 編碼，可以有效防止跨站點腳本攻擊。因為通過HTML 編碼，可將大多數腳本命令自動轉換為無害文本。2.8 命令注射漏洞測試命令注射漏洞測試主要檢查所有調用外部資源(例如system、exec、fork，或者所有的發出請求的語法的源代碼，查找那些來自于HTTP 請求的輸入可能發起調用的所有地方。使用相同功能的專門的庫函數來代替shell 命令和一些系統調用，可以抵御命令注射的攻擊，另外一種避免命令注射的保護措施就是確保Web 應用程序只是根據它所要執行某個功能時所需的最小權限來實現這個功能。如果必須使用外部命令的話，任何被插入命令的用戶信息必須仔細地審查，設立一定的機制來處理可能出現的錯誤、超時、或者在調用過程中出現的阻塞。2.9 日志文件測試日志文件測試主要檢查Web 運行的相關信息是否寫進了日志文件、是否可追蹤，是否記錄了系統運行中發生的所有錯誤，是否記錄了用戶的詳細信息，包括用戶的瀏覽器、用戶停留的時間、用戶IP 等。記錄了用戶的IP，就能通過追捕查出用戶的具體地點。錯誤作為日志保留下來，可供技術人員分析錯誤是由系統實現漏洞引起的還是由于黑客攻擊引起的。2.10 訪問控制策略測試訪問控制策略是網絡安全防范和保護的主要策略，其任務是保證網絡資源不被非法使用和非法訪問。各種網絡安全策略必須相互配合才能真正起到保護作用，而訪問控制是保證網絡安全最重要的核心策略之一。訪問控制策略包括入網訪問控制策略、