2.1.1 HTTP 基礎知識（Http Basics） .............................................9
HTTP 是如何工作的呢？所有的 HTTP 傳輸都要遵循同樣的通用格式（需要使用 IEWatch
或 WebScarab 類插件協助進行學習）。每個客戶端的請求和服務端的響應都有三個部分：請
求或響應行、一個報頭部分和實體部分。客戶端以如下方式啟動一個交互：
客戶端連接服務器並發送一個文件請求。
GET /index.html?param=value HTTP/1.0
接下來，客戶端發送可選頭信息，告知接收服務器其配置和文件格式。
User-Agent: Mozilla/4.06 Accept: image/gif, image/jpeg, */*
發送請求和報頭之后，客戶端可以發送更多的數據。該數據主要用於使用 POST 方法的CGI 程序。
2.1.2 HTTP 拆分（HTTP Splitting）..........................................11
攻擊者在向 Web 服務器正常輸入的請求中加入惡意代碼，受到攻擊的應用不會檢查 CR
（回車，也可表示為%0d 或\r）和 LF（換行，也可表示為%0a 或\n）。這些字符不僅使攻擊
者控制應用程序打算發送的響應頭和響應體，而且還使他們能夠完全在其控制下創造更多的
答復。
HTTP 拆分攻擊配合緩存污染一起使用，能使效果達到最大化。緩存污染攻擊的目標是
使緩存污染，欺騙緩存，使其相信使用 HTTP 拆分劫持的頁面是一個很正常的頁面，是一個
服務器的副本。攻擊發生時，使用 HTTP 拆分攻擊，加上最后修改添加的部分：請求頭，並
設置它為將來的日期。這將迫使瀏覽器發送 If ‐ Modified‐ Since 請求頭，這使攻擊者有機會
攔截服務器的答復，並代之以一個“304 不修改”答復。以下是一個簡單的 304 響應：
HTTP/1.1 304 Not Modified
Date: Fri, 30 Dec 2005 17:32:47 GMT
2.2 訪問控制缺陷（Access Control Flaws） ...............................................................19
2.2.1 使用訪問控制模型（Using an Access Control Matrix）...................................19
在一個基於角色的訪問控制方案中，角色代表了一組訪問權限和特權。一個用戶可以被
分配一個或多個角色。一個基於角色的訪問控制方案通常有兩個部分組成：角色權限管理和
角色分配。一個被破壞的基於角色的訪問控制方案可能允許用戶執行不允許他/她的被分配
的角色，或以某種方式允許特權升級到未經授權的角色的訪問。
2.2.2 繞過基於路徑的訪問控制方案（Bypass a Path Based Access Control Scheme）.......................22
在一個基於路徑的訪問控制方案中，攻擊者可以通過提供相對路徑信息遍歷路徑。因此，
攻擊者可以使用相對路徑訪問那些通常任何人都不能直接訪問或直接請求就會被拒絕的文
件。
2.2.3 基於角色的訪問控制（LAB: Role Based Access Control）...............................25
在一個基於角色訪問控制的方案中，角色代表一組訪問權限和特權。一個用戶可以被分
配一個或多個角色，一個基於角色的訪問控制通常包括兩個部分：角色權限管理和角色分配。
一個被破壞的基於角色的訪問控制方案，可能允許用戶以沒有分配他/她的角色或以某種方
式獲得的未經授權的角色進行訪問。
2.2.4 遠程管理訪問（Remote Admin Access）.........................................................36
應用程序通常會有一個管理界面，這個界面一般用戶無法訪問到，只有具有特權的用戶
才能訪問。
2.3 Ajax 安全（Ajax Security）....................................................................................38
AJAX 技術的一項關鍵元素是 XMLHttpRequest（XHR），該技術允許客戶端向服務端發起
異步調用。然而，作為一項安全措施，這些請求最好只能從客戶端原始頁面向服務端發起訪
問。
2.3.1 同源策略保護（Same Origin Policy Protection）.............................................38
同源策略是客戶端腳本（尤其是 Javascript）的重要的安全度量標准。它最早出自於
Netscape Navigator2.0，其目的是防止某個文檔或腳本從多個不同源裝載。
當腳本被瀏覽器半信半疑運行在沙箱時，它們應該只被允許訪問來自同一站點的資源，
而不是那些來自其它站點可能懷有惡意的資源。
2.3.2 基於 DOM 的跨站點訪問（LAB: DOM‐Based cross‐site scripting）................39
文檔對象模型（DOM）從安全的角度展現了一個有趣的問題。它允許動態修改網頁內
容，但是這可以被攻擊者用來進行惡意代碼注入攻擊。XSS，一種惡意代碼注入，一般會發
生在未經驗證的用戶的輸入直接修改了在客戶端的頁面內容的情況下。
2.3.3 小實驗：客戶端過濾（LAB: Client Side Filtering）..........................................43
服務端只向客戶端發送其只能訪問到的數據。在本課程中，服務端向客戶端發送了過多
的數據，由此產生了一個嚴重的訪問控制問題。
2.3.4 DOM 注入（DOM Injection）............................................................................46
一些應用程序專門使用 AJAX 操控和更新在 DOM 中能夠直接使用的 JavaScript、DHTML
和 eval()方法。攻擊者可能會利用這一點，通過攔截答復，注入一些 JavaScript 命令，實施攻
擊。
2.3.5 XML 注入（XML Injection） ..............................................................................49
AJAX 應用程序使用 XML 與服務端進行信息交互。但該 XML 內容能夠被非法用戶輕易攔
截並篡改。
2.3.6 JSON 注入（JSON Injection）............................................................................52
javaScript Object Notation (JSON)是一種簡單的輕量級的數據交換格式，JSON 可以
以很多形式應用，如：數組，列表，哈希表和其他數據結構。JSON 廣泛應用於 AJAX 和
web2.0 應用。相比 XML，JSON 得到程序員的更多的青睞，因為它使用更簡單，速度更快。
但是與 XML 一樣容易受到注入攻擊，惡意攻擊者可以通過在請求響應中注入任意值。
2.3.7 靜默交易攻擊（Silent Transactions Attacks）..................................................54
對客戶端來說，任何一個靜默交易攻擊，使用單一提交的系統都是有危險的。舉例來說，
如果一個正常的 web 應用允許一個簡單的 URL 提交，一個預設會話攻擊將允許攻擊者在沒
有用戶授權的情況下完成交易。在 Ajax 里情況會變得更糟糕：交易是不知不覺的，不會在
頁面上給用戶反饋，所以注入的攻擊腳本可以在用戶未授權的情況下從客戶端把錢偷走。
2.3.8 危險指令使用（Dangerous Use of Eval）.........................................................57
在服務端驗證所有用戶輸入的信息，這是一個不錯的做法。如果未驗證的用戶輸入直接
通過 HTTP 響應返回給客戶端的話，往往會觸發 XSS 攻擊。
在這一課中，未驗證的用戶提供的數據結合了 JavaScript 的 eval()調用一起使用。在反射
型 XSS 攻擊中，攻擊者可以構造帶有攻擊腳本的 URL，將其存儲於其他站點，通過電子郵件，
或者其他方式誘騙用戶點擊，達到 XSS 的目的。
2.3.9 不安全的客戶端存儲（Insecure Client Storage）............................................59 *********************
在服務端驗證所有的用戶輸入信息總是不錯的做法。客戶端進行的任何驗證信息都存在
被逆向分析的脆弱性。記住，客戶端的任何數據都不能被視為機密！
客戶端 HTML 和 JavaScrip 語句可以對網頁內容、形式做修改，如隱藏、控制讀寫、限
制長度等。同樣，通過修改網頁代碼也能解除此類限制。
2.4 認證缺陷（Authentication Flaws）.......................................................................62
2.4.1 密碼強度（Password Strength）.......................................................................62
密碼是賬戶安全的保障。多數用戶都在各個網站上使用同樣的弱密碼。如果您想您的應
用程序不被攻擊者暴力破解，應該設置一個較好的密碼。好的密碼應包含小寫字母、大寫字
母和數字。密碼越長，效果越好。
2.4.2 忘記密碼（Forgot Password）..........................................................................64
Web 應用程序經常為用戶提供密碼找回功能。但不幸的是，很多 Web 應用程序的實施
機制並不正確。驗證用戶身份所需要的信息往往過於簡單。
2.4.3 基本認證（Basic Authentication）....................................................................66
基本身份驗證通常用來保護服務端的資源。Web 服務器將發送 401 認證請求與所請求
的資源響應。客戶端瀏覽器會提示用戶在瀏覽器提供的對話框中輸入用戶名和密碼。瀏覽器
將用戶名和密碼使用 Base64 編碼方式進行編碼，並將這些憑據發送給 Web 服務器。Web
服務器會驗證這些憑據，如果所提供的憑據正確，則返回所請求的資源。這些憑據會自動重
置每一個使用這一機制的被保護的頁面，而不需要用戶再次輸入這些憑據。
基本認證使用 cookie 傳遞認證信息，可以使用代理工具攔截請求並查看 cookie。
2.4.4 多級登錄 1（Multi Level Login 1） ...................................................................71
多級登錄提供了一個健壯的驗證。這是加入第二層的存檔。在通過您的用戶名密碼登錄
后，您可以請求一個“交易認證號（TAN）”。這經常用於網上銀行。您得到一個銀行提
供的由很多交易認證號生成唯一的列表，每個交易認證號只能使用一次。另一種方法是用短
信提供一個交易認證號，這樣做的好處是攻擊者無法獲得用戶的交易認證號。 很多用過的驗證碼往往能夠被再次使用。
2.4.5 多級登錄 2（Multi Level Login 2） ...................................................................73
參考上節:
在這一課中，您將要嘗試破壞這種認證，通過其他賬號進行登錄。您需要做的是通過其
他賬號登錄，在只知道目標用戶名的情況下，以該用戶名身份登錄系統。
2.5 緩沖區溢出（Buffer Overflows）..........................................................................74
緩沖區溢出是指當計算機向緩沖區內填充數據位數時超過了緩沖區本身的容量，溢出的
數據覆蓋在合法數據上。理想的情況是程序檢查數據長度並不允許輸入超過緩沖區長度的字
符，但是絕大多數程序都會假設數據長度總是與所分配的儲存空間相匹配，這就為緩沖區溢
出埋下隱患。
2.5.1 Off‐by‐One 緩沖區溢出（Off‐by‐One Overflows） .........................................74
通過向程序的緩沖區寫入超出其長度的內容，導致緩沖區的溢出，從而破壞程序的堆棧，
造成程序崩潰或使程序轉而執行其它指令，以達到攻擊的目的。造成緩沖區溢出的原因是程
序中沒有仔細檢查用戶輸入的參數。
緩沖區溢出是一種非常普遍、非常危險的漏洞，在各種操作系統、應用軟件中廣泛存在。
利用緩沖區溢出攻擊，可以導致程序運行失敗、系統宕機、重新啟動等后果。更為嚴重的是，
可以利用它執行非授權指令，甚至可以取得系統特權，進而進行各種非法操作。
2.6 代碼質量（Code Quality）....................................................................................78
2.6.1 在 HTML 中找線索（Discover Clues in the HTML） .........................................78
眾所周知，很多開發者喜歡在源代碼中保存 FIXME's、Code Broken、Hack 等語句。通
過審查源代碼中的相關注釋往往能找到密碼、后門及一些潛在的問題。
2.7 並發（Concurrency） ...........................................................................79
2.7.1 線程安全問題（Thread Safety Problems）.......................................................79
Web 應用程序可以同時處理很多 HTTP 請求。開發人員經常使用的變量不是線程安全
的。線程安全是指一個對象或類的領域在多線程同時使用的時候總是保持有效的狀態。它往
往可以利用並發錯誤，精確地在同一時間同一個頁面加載另一個用戶。
因為所有的線程共享同一個方法區，而所有的類變量存儲在方法區，多個線程試圖同時
使用相同的類變量。
用戶利用 Web 應用程序中的並發錯誤，查看同一時間另一個用戶試圖登錄同一個功能
的信息。
2.7.2 購物車並發缺陷（Shopping Cart Concurrency Flaw） ....................................80
Web 應用程序可以同時處理很多 HTTP 請求。開發人員經常使用的變量不是線程安全
的。線程安全是指一個對象或類的領域在多線程同時使用的時候總是保持有效的狀態。它往
往可以利用並發錯誤，精確地在同一時間同一個頁面加載另一個用戶。
因為所有的線程共享同一個的方法區，所有的類變量存儲在方法區，多個線程試圖同時
使用相同的類變量。
2.8 跨站腳本攻擊（Cross‐Site Scripting (XSS)）.........................................................82
2.8.1 使用 XSS 釣魚（Phishing with XSS）.................................................................82
在服務端對所有輸入進行驗證總是不錯的做法。當用戶輸入非法 HTTP 響應時容易造成
XSS。在 XSS 的幫助下，您可以實現釣魚工具或向某些官方頁面中增加內容。對於受害者
來說很難發現該內容是否存在威脅。
2.8.2 小實驗：跨站腳本攻擊（LAB: Cross Site Scripting） ......................................84
輸入驗證是一個很好的方法，尤其是驗證那些以后將用做參數的操作系統命令、腳本和
數據庫查詢的輸入。尤為重要的是，這些內容將會永久的存放在那里。應當禁止用戶創建消
息內容。用戶的信息被檢索時，可能導致其他用戶加載一個不良的網頁或不良的內容。當一
個未經驗證的用戶的輸入作為一個 HTTP 響應時，XSS 攻擊也可能會發生。在一個反射式
XSS 攻擊中，攻擊者會利用攻擊腳本精心制作一個 URL 並通過將其發送到其他網站、電子
郵件、或其他方式騙取受害者點擊它。
2.8.3 存儲型 XSS 攻擊（Stored XSS Attacks） ...........................................................90
過濾所有用戶輸入是一個不錯的做法，特別是那些后期會被用作 OS、腳本或數據庫查
詢參數的輸入。尤其是那些將要長期存儲的內容。用戶不能創建非法的消息內容，例如：可
以導致其他用戶訪問時載入非預期的頁面或內容。
2.8.4 跨站請求偽造（Cross Site Request Forgery (CSRF)）.......................................91
跨站請求偽造是一種讓受害者加載一個包含網頁的圖片的一種攻擊手段。如下代碼所示：
<img src="http://www.mybank.com/sendFunds.do?acctId=123456"/>
當受害者的瀏覽器試圖打開這個頁面時，它會使用指定的參數向 www.mybank.com 的
transferFunds.do 頁面發送請求。瀏覽器認為將會得到一個圖片，但實際上是一種資金轉移
功能。該請求將包括與網站相關的任何 cookies。因此，如果用戶已經通過網站的身份驗證，
並有一個永久的 cookie，甚至是當前會話的 cookie，網站將沒有辦法區分這是否是一個從合
法用戶發出的請求。通過這種方法，攻擊者可以讓受害者執行一些他們本來沒打算執行的操
作，如注銷、采購項目或者這個脆弱的網站提供的任何其他功能
2.8.5 繞過 CSRF 確認（ CSRF Prompt By‐Pass）.......................................................93 **********
網頁中所有手動發起的請求操作，其實質是通過 HTML+JavaScript 向服務器發起請求。
類似於 CSRF 課程，您的目標是給新聞組發送一封帶有多個威脅請求的 Email。第一個請
求用戶資金轉賬，第二個用於自動處理第一個請求所觸發的確認。URL 必須使用以下兩個外
部參數“transferFunds=4000”和“transferFunds=CONFIRM”。可以通過在左側鏈接中右鍵鼠
標，復制快捷方式完成 URL 獲取。任何收到該郵件的人若正好已經通過認證，則當其訪問
該頁面時將自動完成資金轉賬。
2.8.6 繞過 CSRF Token（CSRF Token By‐Pass）..........................................................98
本節課程將指導您如何在啟用 CSRF Token 防護的網站上發起跨站請求偽造攻擊
（CSRF）。
跨站請求偽造攻擊（CSRF/XSRF）欺騙用戶（那些已經獲取了系統的信任）點擊帶有
偽造請求的頁面從而執行相關命令。
基於 Token 的請求認證用於阻止此類攻擊者。該技術在請求發起頁面插入 Token。Token
用於完成請求和並驗證該操作不是通過腳本執行的。OWASP 提供的 CSRFGuard 使用該技
術以阻止 CSRF 攻擊。盡管如此，但如果該站點存在 XSS 攻擊漏洞，則該技術可被繞過。由於瀏覽器同源策
略，相同域名下的頁面能夠讀取其它頁面的內容。
2.8.7 HTTPOnly 測試（HTTPOnly Test）...................................................................102
為了降低跨站腳本攻擊的威脅，微軟引入了新的 cookie 屬性字段：“HTTPOnly”。一
旦該字段被標記，瀏覽器將禁止客戶端腳本訪問 Cookie。由於該屬性相對較新，有些瀏覽
器還無法正確處理這個屬性
2.8.8 跨站跟蹤攻擊（Cross Site Tracing (XST) Attacks）.........................................103
過濾所有用戶輸入是一個不錯的做法，特別是那些后期會被用作 OS、腳本或數據庫查
詢參數的輸入。尤其是那些將要長期存儲的內容。用戶不能創建非法的消息內容，例如：可
以導致其他用戶訪問時載入非預期的頁面或內容。
2.9 不當的錯誤處理（Improper Error Handling） ...................................................105
2.9.1 打開認證失敗方案（Fail Open Authentication Scheme）.............................105
本節課程介紹了關於認證“無法打開”的基本知識。用安全術語來講，“fail open”描
述了一個驗證機制的行為。這是一個驗證方法的驗證結果為“true”時發生的錯誤（意外的
異常）。在登錄過程中，這是特別危險的。
Java 代碼中異常處理部分為成功認證行為進行異常捕獲。該異常產生是因為密碼字段使
用了空指針。.
2.10 注入缺陷（Injection Flaws）...............................................................................107
2.10.1 命令注入（Command Injection）...................................................................107
命令注入攻擊對任何一個以參數驅動的站點來說都是一個嚴重威脅。這種攻擊技術背后
的技術方法，簡單易學，能造成大范圍的損害，危及系統安全。盡管這類風險數目令人難以
置信，互聯網中的系統很容易受到這種形式的攻擊。
這種攻擊容易擴散，造成更壞的影響。但是對於這類威脅，一點常識和預先預防幾乎可
以完全阻止。這節課將為學員展示幾個參數注入的例子。
“清洗”所有輸入數據總是不錯的做法，尤其是那些將被用於操作系統命令、腳本和數
據庫查詢語句的數據。在正常的參數提交過程中，添加惡意的代碼，往往能夠得到以外的收獲。
2.10.2 數字型 SQL 注入（Numeric SQL Injection）...................................................109
SQL 注入攻擊對任何一個以數據庫作為驅動的站點來說都是一個嚴重威脅。這種攻擊
技術背后的技術方法，簡單易學，能造成大范圍的損害，危及系統安全。盡管這些風險數目
令人難以置信，互聯網中的系統很容易受到這種形式的攻擊。
這種攻擊容易擴散，造成更壞的影響，但是對於這類威脅，一點常識和預先預防幾乎可
以完全阻止。這節課將為學員展示幾個參數注入的例子。
盡管 SQL 注入威脅可能已經通過其它方式被攔截，但“清洗”所有輸入數據總是不錯
的做法，尤其是那些將被用於操作系統命令、腳本和數據庫查詢語句的數據。
2.10.3 日志欺騙（Log Spoofing）..............................................................................110
這種攻擊是在日志文件中愚弄人的眼睛，攻擊者可以利用這種方式清除他們在日志中的
痕跡。
2.10.4 XPATH 型注入（XPATH Injection） ..................................................................112
與 SQL 注入類似，XPATH 注入發生在當網站使用用戶提供的信息查詢 XML 數據時。
通過向網站故意發送異常信息，攻擊者可以發現 XML 數據的結構或訪問那些本來無法訪問
到的數據。如果該 XML 是一個用戶認證文件（例如一個基於 XML 的用戶文件），攻擊者
還能借此提升自己在網站中的特權。使用 XPATH 查詢 XML，通過一個簡單的描述性語句
類型，允許 XML 查詢，找到一條信息。像 SQL 一樣，您可以指定找到的某些屬性與模式
匹配。
當一個網站中使用 XML，它是普遍接受某種形式的輸入，查詢字符串，找到並將標識
的內容顯示在頁面上。此類輸入必須進行清洗，以驗證它不會影響 XPATH 的查詢，並返回
錯誤數據。
2.10.5 字符串型注入（String SQL Injection） ...........................................................113
2.10.6 小實驗：SQL 注入（LAB: SQL Injection） ......................................................115
2.10.7 通過 SQL 注入修改數據（Modify Data with SQL Injection）.........................119
someuserid'; UPDATE salaries SET salary=999999 WHERE userid='jsmith
2.10.8 通過 SQL 注入添加數據（Add Data with SQL Injection）..............................120
whatever'; INSERT INTO salaries VALUES ('rlupin',140000);--
2.10.9 數據庫后門（Database Backdoors） ..............................................................121
數據庫通常作為一個 Web 應用程序的后端來使用。此外，它也用來作為存儲的媒介。
它也可以被用來作為存儲惡意活動的地方，如觸發器。觸發器是在數據庫管理系統上調用另
一個數據庫操作，如 insert, select, update or delete。舉個例子：攻擊者可以創建一個觸發器，
該觸發器在創建新用戶時，將每個新用戶的 Email 地址設置為攻擊者的地址。
101;CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN
UPDATE employee SET email='john@hackme.com' WHERE userid = NEW.userid
2.10.10 數字型盲注入（Blind Numeric SQL Injection）..................................123
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') = 2364 );
2.10.11 字符串型盲注入（Blind String SQL Injection） ..................................124
101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), 1, 1) <'H' );
2.11 拒絕服務（Denial of Service）............................................................................126
2.11.1 多個登錄引起的拒絕服務（Denial of Service from Multiple Logins）..........126
拒絕服務攻擊是 Web 應用程序中的主要問題。 如果最終用戶不能開展業務或執行由
Web 應用程序所提供的服務，則是浪費時間和金錢。數據庫連接總是要占用移動資源的；過度使用會影響系統性能。
2.12 不安全的通信（Insecure Communication）.......................................................127
敏感數據不能用明文發送，通常在驗證后要切換到安全連接。攻擊者可通過嗅探獲得的
登錄信息和收集到的其他信息入侵賬戶。一個好的 Web 應用程序總是使用加密方式發送敏
感數據。
2.12.1 不安全的登錄（Insecure Login）....................................................................127
2.13 不安全的配置（Insecure Configuration）..........................................................130
2.13.1 強制瀏覽（How to Exploit Forced Browsing）................................................130
強制瀏覽是黑客用來訪問獲取那些沒有被引用，但仍然允許被訪問的資源的技術。一種
方法是操縱瀏覽器中的 URL，刪除結尾部分，直到找到一個不受保護的目錄。
2.14 不安全的存儲（Insecure Storage）....................................................................131
2.14.1 強制瀏覽（How to Exploit Forced Browsing）................................................131
2.15 惡意執行（Malicious Execution）.......................................................................132
2.15.1 惡意文件執行（Malicious File Execution）....................................................132
很多網站允許用戶上傳文件，例如：圖片或是視頻。 如果確實有效的安全措施，包含
惡意指令的文件會被上傳到服務器並執行。
2.16 參數篡改（Parameter Tampering）....................................................................134
2.16.1 繞過 HTML 字段限制（Bypass HTML Field Restrictions） .............................134
客戶端驗證不應該被認為是一種安全的參數驗證方法。這種驗證方式只能幫那些不知道
所需輸入的用戶縮短服務器處理時間。攻擊者可以用各種方法輕易的繞過這種機制。任何客
戶端驗證都應該復制到服務器端。這將大大減少不安全的參數在應用程序中使用的可能性。
在這個練習中，每個輸入框中有不同的輸入要求，您要做的就是繞過客戶端驗證機制破壞這
些規則，輸入不允許輸入的字符。
2.16.2 利用隱藏字段（Exploit Hidden Fields）.........................................................136
開發人員在加載信息的頁面上使用隱藏字段來跟蹤、登錄、定價等。雖然這是一種方便
且易於開發的機制，他們往往不驗證從隱藏字段收到的信息。本課程中，我們將了解如何找
到和修改隱藏字段以便宜的價格購買產品.
2.16.3 利用未檢查的 E‐mail（Exploit Unchecked Email） ........................................138
驗證所有的輸入信息總是不錯的做法。多數網站都允許一個非驗證的用戶給“朋友”發
送 e-mail。對垃圾郵件發送者來說，這是一個絕佳的機制，可以利用公司的郵件服務器來發
送電子郵件。
2.16.4 繞過客戶端 JavaScript 校驗（Bypass Client Side JavaScript Validation）......142
客戶端驗證不應該被認為是一種安全的方法驗證參數。這種驗證方式只能幫那些不知道
所需輸入的用戶縮短服務器處理時間。攻擊者可以用各種方法輕易的繞過這種機制。任何客
戶端驗證都應該復制到服務器端。這將大大減少不安全的參數在應用程序中使用的可能性。
在這個練習中，每個輸入框中有不同的輸入要求，您要做的就是繞過客戶端驗證機制破壞這
些規則，輸入不允許輸入的字符。
2.17 會話管理缺陷（Session Management Flaws） ..................................................148
2.17.1 會話劫持（Hijack a Session） .........................................................................148
開發人員在開發他們的自有會話 ID 時經常忘記整合的復雜性和隨機性，這些因素對安
全來說是必須的。如果用戶的特定的會話 ID 不具備復雜和隨機性，那么應用程序很容易受
到基於會話的暴力攻擊的威脅.會話 ID 一般由 Session 生成，存儲在客戶端 Cookie 的某個字段中。
2.17.2 認證 Cookie 欺騙（Spoof an Authentication Cookie）...................................154
如果驗證 cookie 正確，一些應用程序會允許一個用戶自動登錄到他們的網站。如果能
夠獲得生成 cookie 的算法，有時 cookie 的值是可以猜到的。有時候 cookie 可能是通過跨站
攻擊截獲的。在這一課中，我們的目的是了解身份驗證 cookie 的方式，並指導您學習突破
這種身份驗證 cookie 的方法
2.17.3 會話固定（Session Fixation）.........................................................................158
服務器通過每個用戶的唯一的 Session ID 來確認其合法性。如果用戶已登錄，並且授權
他不必重新驗證授權時，當他重新登錄應用系統時，他的 Session ID 依然是被認為合法的。
在一些程序中，可能會在 GET-REQUEST 請求中傳遞 Session ID。這就是攻擊的起點。
一個攻擊者可以用一個選定的 Session ID 給受害人發送一個超鏈接。例如，這里有一個
准備好的郵件，它看起來像是一個從應用程序管理員發來的官方郵件。如果受害者點擊了這
個鏈接，並且該受害者以攻擊者指定的 ID 登錄了系統；那么攻擊者可以不經授權直接使用
與受害者相同的 ID 訪問該頁
2.18 Web 服務（Web Services）.................................................................................162
2.18.1 創建 SOAP 請求（Create a SOAP Request）...................................................162
Web Services 通過使用 SOAP 請求進行通信。這個請求提交到一個嘗試執行一個 Web 服
務描述語言（WSDL）定義的函數的 Web 服務。讓我們一起來學習一些關於 WSDL 的文件。
查看一下 WebGoat 的 WSDL 文件。
2.18.2 WSDL 掃描（WSDL Scanning） .......................................................................168
Web Services 通過使用 SOAP 請求進行通信。這個請求提交到一個嘗試執行一個 Web 服
務描述語言（WSDL）定義的函數的 Web 服務。讓我們一起來學習一些關於 WSDL 的文件。
查看一下 WebGoat 的 WSDL 文件。
2.18.3 Web Service SAX 注入（Web Service SAX Injection）.....................................170
Web Services 通過使用 SOAP 請求進行通信。這個請求提交到一個嘗試執行一個 Web 服
務描述語言（WSDL）定義的函數的 Web 服務。讓我們一起來學習一些關於 WSDL 的文件。
查看一下 WebGoat 的 WSDL 文件
2.18.4 Web Service SQL 注入（Web Service SQL Injection）.....................................172
2.19 管理功能（Admin Functions）............................................................................175
2.19.1 報告卡（Report Card） ...................................................................................175
2.20 挑戰（Challenge）...............................................................................................176
2.20.1 挑戰（The CHALLENGE!） ...............................................................................176