（一）WebGoat部署
安裝Tomcat
在官網下載Tomcat 7.0版本的zip包到本地，解壓。（用8.0版登陸不上webgoat）
新建兩個系統變量CATALINA_BASE和CATALINA_HOME，變量值均為Tomcat的安裝目錄，例如F:\Webgoat\apache-tomcat-7.0.82。在Path變量中添值%CATALINA_HOME%\lib;%CATALINA_HOME%\bin。
cmd或powershell移動到安裝目錄下的bin文件夾，執行命令servic.bat install。
配置WebGoat
下載WebGoat5.4版本的war包,放到Tomcat目錄的webapps子目錄下。
在conf目錄下的tomcat-users.xml文件中加入以下內容。
<role rolename="manager"/>
<role rolename="webgoat_basic"/>
<role rolename="webgoat_admin"/>
<role rolename="webgoat_user"/>
<user username="admin" password="admin" roles="manager-gui"/>
<user username="webgoat" password="webgoat" roles="webgoat_admin"/>
<user username="basic" password="basic" roles="webgoat_basic,webgoat_user"/>
<user username="guest" password="guest" roles="webgoat_user"/>
登陸WebGoat
打開bin目錄下的tomcat7w.exe程序，啟動Tomcat。
地址欄輸入localhost:8080/WebGoat-5.4/attack，用戶名和密碼均輸入guest，即可進入WebGoat主頁。
（二）General
HTTP基礎
請求報文結構：
請求頭：
- If-Modified-Since：說明瀏覽器最后一次收到資源的時間，如果自此之后資源沒有更新，服務器會返回 304 響應指示瀏覽器使用緩存副本；
- Accept-Encoding：願意接收的內容編碼；
- Referer：提出當前請求的原始URL；
- Authorization：為一種內置的HTTP身份驗證提交證書；
響應報文結構：
響應頭：
- Location：說明重定向響應的目標；
- Cache-Control：向瀏覽器傳送緩存指令；
- Expires：說明消息主體的有效時間，在此之前，瀏覽器可以使用緩存副本；
狀態碼
- 301 Moved Permanently：永久重定向，新URL將替換原始URL；
- 302 Found：臨時重定向，在隨后的請求中恢復原始URL；
- 304 Not Modified：指示瀏覽器使用緩存副本；
- 400 Bad Request：無效的http請求；
HTTP Splitting
如果應用不檢查輸入請求中的 CRLF（Carriage-Return Line-Feed），攻擊者可以通過回車符（\r）和換行符（\n）插入消息頭和消息體，控制響應信息
例如，在表單中填入字符串
foobar%0d%0aContent‐Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent‐Type:%20text/html%0d%0aContent‐Length:%2047%0d%0a%0d%0a<html>Hacked J</html>
可以構造以下報文
Foobar
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 47
<html>Hacked J</html>
注入特殊字符后，HTTP 響應數據包中“Content‐Length: 0”告訴瀏覽器響應已經結束。再通過隨后的報文傳送一個新頁面
緩存污染：HTTP頭中的 Last‐Modified 字段設置為一個未來時間，迫使瀏覽器發送 If‐Modified‐Since 請求頭
（三）Access Control Flaws
- 繞過表示層訪問控制
登陸賬戶“Tom Cat”，使用ViewProfile功能，攔截請求包將動作改為DeleteProfile
- 繞過基於路徑的訪問控制
攔截請求，修改請求路徑以繞到其他目錄。
例如：../../../../../conf/tomcat-users.xml
- 繞過數據層訪問控制
修改 request 中的employee_id參數，惡意訪問其他人的資料
- 遠程管理界面
利用開發人員預留的參數接口訪問管理界面，例如，在URL添加參數&admin=true
（四）Ajax Security
- 在表單利用HTML標簽可構造DOM型XSS
- 客戶端的數據都是不安全的
- 查看HTML源碼可以看到一些隱藏信息，或者修改一些元素的屬性。例如，刪除
readonly=""可以修改一些本不允許修改的數據 - 閱讀 Javascript 理解其工作流程，可以繞過一些客戶端的驗證，或者得到一些隱藏信息
- XML 注入和 JSON 注入：修改 respond 的 XML 和 JSON 數據
- 靜默交易攻擊：通過瀏覽器直接執行 Javascript 中的功能函數完成交易。很多瀏覽器支持在地址欄輸入類似
javascript:function();的語句執行 JavaScript
（五）Authentication Flaws
- 弱口令
利用忘記密碼功能，通過暴力破解回答問題，得到密碼或設置新密碼
- 基本身份認證
客戶端用Authorization頭提供 Base64 編碼的用戶名和密碼，修改 Authorization 頭可以更改賬戶。但 Cookie 不變的話頁面信息不會變
- 多級登陸
- 修改參數使已經用過的 TAN（Transaction Authentication Number）驗證碼仍然生效
- 修改 user 相關的參數訪問其他用戶的信息
（六）Buffer Overflows
當計算機向緩沖區內填充數據位數時超過了緩沖區本身的容量，溢出的數據會覆蓋在合法數據上。
- 攔截請求后發送到Intruder，將參數 room_no 設為溢出目標。
- 攻擊類型為 sniper，方案為 character blocks（大量的字符填充）。
- 設置好輸入值，最小、最大值，步長，然后發送payload。
（七）Code Quality
從頁面源碼中找到泄漏的敏感信息，例如在注釋中
（八）Concurrency
線程安全是指一個對象或類的領域在多線程同時使用的時候總是保持有效的狀態。它往往可以利用並發錯誤，精確地在同一時間、同一個頁面加載另一個用戶。因為所有的線程共享同一個方法區，而所有的類變量存儲在方法區，多個線程試圖同時使用相同的類變量。
原因：
-
Web應用程序可以同時處理很多HTTP請求
-
開發人員經常使用的變量不是線程安全的
后果：
用戶利用 Web 應用程序中的並發錯誤， 可以查看同一時間中，另一個用戶試圖登錄同一個功能的信息。也可以利用並發缺陷查看他人信息或者篡改購物車付款金額。
（九）Cross-Site Scripting
存儲型XSS
登陸 tom 的賬戶，修改 Street 一欄的信息為<script>alert("Hey guy!")</script>。用 Jerry 的賬戶查看 Tom 的資料時會受到 XSS 攻擊而彈出警告。
可使用輸入驗證來阻止上傳 XSSPayload，而已經存儲在服務端的 XSSPayload 可以通過輸出編碼阻止。
反射型XSS
構造一個包含 XSSPayload 的 URL，在服務端返回的 response 中，URL 上的 XSSPayload 會被當成頁面源代碼執行。
Cross Site Request Forgery（CSRF）
例：發送一封帶有<img>標簽圖片的郵件，利用 src 屬性指向一個惡意請求
繞過確認
先提交一個<iframe>或<img>構造惡意請求，再用一個標簽指向第一個請求觸發的確認（注意要先后生效）
繞過Token
Anti-CSRF token：在請求發起頁面插入Token用於完成請求和並驗證該操作不是通過腳本執行的。
先使用一個<iframe>打開頁面，用 JS 讀取出Token；然后加載另一個<iframe>，並使用第一個<iframe>讀取的 Token 發送請求。
HTTPOnly
微軟引入的新的 cookie 屬性字段，被標記 HTTPOnly 字段后瀏覽器將禁止客戶端腳本訪問 Cookie
跨站跟蹤攻擊
嵌入 Ajax 請求，利用 HTTP TRACE 方法（回顯服務器收到的請求，主要用於測試或診斷）
（十）Improper Error Handling
例：攔截請求，刪除 password 參數，Java 代碼會捕獲空指針異常使得認證被繞過
（十一）Injection Flaw
命令注入
原理：修改提交的參數，使服務器執行惡意命令
防范：“清洗”所有輸入數據是不錯的防御方法，尤其是那些將被用於操作系統命令、腳本和數據庫查詢語句的數據
SQL注入
數字型SQL注入
注入參數為整型（ID、年齡、頁碼等），不需要單引號閉合。
字符串型SQL注入
通常使用單引號閉合參數，例如，在密碼框輸入error'or'1'='1可繞過密碼認證。
通過SQL注入操作數據
修改：注入UPDATE命令，例如：someuserid'; UPDATE salaries SET salary=999999 WHERE userid='jsmith
添加：注入INSERT命令，例如：someuserid';INSERT INTO salaries VALUES ('zrquan',9999999);--
盲注
-
某些SQL注入是沒有明確返回信息的，只能通過條件的“真”和“假”進行判斷
例：
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );可以判斷PIN值是否大於1000，以此類推縮小范圍，最終確定其值 -
SUBSTRING 方法用來截取字符串，可以使用該方法進行字符串型的盲注
SUBSTRING(STRING,START,LENGTH)例：
101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), 1, 1) < 'H' );可以判斷PIN字段的第一個字符是否小於H，經過多次測試（比較0-9 A-Z a-z等字符串可以確定每一個字符的值
日志欺騙
向日志添加虛假信息或插入腳本，管理員通過瀏覽器觀看日志時惡意腳本會被執行
XPATH注入
XPATH：用於在文檔中查找XML數據的語言
與 SQL 注入類似，XPATH 注入發生在當網站使用用戶提供的信息查詢 XML 數據時。通過向網站故意發送異常信息，攻擊者可以發現 XML 數據的結構或訪問那些本來無法訪問到的數據。
數據庫后門
觸發器是在數據庫管理系統上調用另一個數據庫操作，如insert, select, update or delete(MySQL不支持觸發器）
舉個例子：攻擊者可以用下面的命令創建一個觸發器，該觸發器在創建新用戶時，將每個新用戶的 Email 地址設置為攻擊者的地址
someuserid;CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='john@hackme.com' WHERE userid = NEW.userid
（十一）Denial of Service（DOS）
例：服務器允許兩個用戶同時登陸，通過 SQL 注入獲取其他合法用戶的密碼，登陸三個用戶，將會使服務器過度使用
（十二）Insecure Communication
敏感數據不能用明文發送，通常在驗證后要切換到安全連接，因為攻擊者可通過嗅探獲得的
登錄信息和收集到的其他信息入侵賬戶。一個好的Web 應用程序總是使用加密方式發送敏
感數據。
使用 HTTPS 訪問后，所有數據被加密。服務器與應用程序通訊將通過傳輸層安全（Transport Layer Security TLS)），又稱為安全套接字層（Secure Socket Layer(SSL)）。TLS 是一種混合的加密協議，通過一個主密鑰來建立通信。這個密鑰使用的是 SHA-1 或 MD5 。
（十三）Insecure Configuration
利用不安全配置漏洞強行瀏覽一些禁止訪問的資源，例如，蠻力猜測資源路徑/WebGoat/config, /WebGoat/configuration, /WebGoat/conf等，可發現隱藏頁面
（十四）Malicious Execution（惡意執行）
利用漏洞上傳包含惡意指令的文件到服務器並執行，腳本后門就屬於典型的惡意文件
例如，上傳一個包含java代碼的文件，通過訪問該文件執行代碼創建一個新文件：
<html>
<% java.io.File file = new java.io.File("F:\\Webgoat\\apache-tomcat-7.0.82\\webapps\\WebGoat-5.4\\guest.txt"); file.createNewFile(); %>
</html>
（十五）Parameter Tampering
- 篡改參數
客戶端驗證不應該被認為是一種安全的參數驗證方法，這種驗證方式只能幫那些不知道所需輸入的用戶縮短服務器處理時間，攻擊者可以用各種方法輕易的繞過這種機制。任何客戶端驗證都應該復制到服務器端，這將大大減少不安全的參數在應用程序中使用的可能性。
漏洞利用：用開發者工具修改客戶端的一些限制，配合攔截工具可輕易修改參數
- 隱藏字段
開發人員在加載信息的頁面上使用隱藏字段來跟蹤、登錄、定價等。雖然這是一種方便且易於開發的機制，但他們往往不驗證從隱藏字段收到的信息。
漏洞利用：通過開發者工具可以看到隱藏的 html 元素，並對其進行惡意篡改
- 未檢查的E-mail
多數網站都允許一個非驗證的用戶給“朋友”發送 e-mail 。對垃圾郵件發送者來說，這是一個絕佳的機制，可以利用公司的郵件服務器來發送電子郵件。
漏洞利用：將隱藏域中的郵箱修改為目標郵箱
（十六）Session Management Flaws
cookie認證欺騙
許多應用程序自動記錄登錄站點的用戶指定 Cookie，如果使用算法生成的 Cookie 都能獲得，則Cookie可以被猜解。而且一些被放到客戶端上的 Cookie 可能被跨站攻擊盜取。
例：
- 分別用 webgoat 和 aspect 兩個賬號登陸，截取到服務端返回的 cookie 值是
AuthCookie=65432ubphcfx和AuthCookie=65432udfqtb - 兩個 cookie 值的數字位沒變，英文字符串則是用戶名倒過來后再向后推一位，可以推測出用戶 alice 的 cookie 是
AuthCookie=65432fdjmb - 截取請求並添加推測的 cookie 值，可以成功通過登陸認證
會話劫持
應用開發者開發會話ID時，經常忘記配置復雜性和隨機性，如果一個用戶的特定會話ID不夠復雜和隨機則很容易遭受到蠻力攻擊。
會話固定
原理：
服務器通過每個用戶唯一的 SessionID 來確認其合法性。如果用戶已登錄，並且授權他不必重新驗證授權，則當他重新登錄應用系統時，他的 Session ID 依然是被認為合法的。
漏洞利用：
攻擊者可以用一個選定的 SessionID 給受害人發送一個超鏈接。例如，准備好一封惡意郵件，它看起來像是一個從應用程序管理員發來的官方郵件。如果受害者點擊了鏈接，並且該受害者以攻擊者指定的 ID 登錄了系統；那么攻擊者可以不經授權直接使用與受害者相同的ID訪問該頁面。
（十七）Web Services
SOAP請求
SOAP：
基於 XML 的簡易協議，可使應用程序在 HTTP 之上進行信息交換；
WSDL：
Web Services Description Language，是一門基於 XML 的語言，用於描述 Web Services 以及如何對它們進行訪問；
截取請求並調用任何方法，用SOAPAction:頭發送一個SOAP（簡單對象訪問協議）請求的有效賬戶
WSDL掃描
攔截請求，修改 field 參數獲取信息
SQL注入
- 使用 WebScarab 的 WebServices 模塊，看到調用的 Web 服務或者 WSDL 歷史文件
- WebScarab 將解析 XML 文件，所以可以選擇調用的操作，然后輸入一個調用的參數值
- 在“vaule”中輸入
1 or 1=1，（401錯誤表示沒有授權，先insert已認證的cookie）
SAX注入
SAX：全稱 Simple API for XML，是一個用於處理 XML 事件驅動的“推”模型，雖然它不是 W3C 標准，但它卻是一個得到了廣泛認可的API。
SAX 解析器不像 DOM 那樣建立一個完整的文檔樹，而是在讀取文檔時激活一系列事件，這些事件被推給事件處理器，然后由事件處理器提供對文檔內容的訪問。
SAX解析器會解析任何格式正常的XML文件。
例：只要匹配到有效的標記符號及閉合符號即認為正確。當您向原有的XML文件中添加新的 changePassword 元素時，如果 id 和 password 等標記都正確，那么解析器將很樂意幫您去修改另一個 userid 的密碼（有點像 DOM XSS）。
更改密碼時提交以下代碼：
newpassword</password>
</wsns1:changePassword>
<wsns1:changePassword>
<id xsi:type='xsd:int'>102</id>
<password xsi:type='xsd:string'>notforyoutoknow
（十八）Challenge
目標
破壞身份驗證方案，從數據庫中盜取所有的信用卡信息，然后破壞頁面"webgoat_challenge_guest.jsp"
stage1
越權登陸，一般有兩種方法：
- 通過認證用戶的身份登陸
- 利用注入漏洞
-
首先嘗試找到注入點，發現輸入可能可以注入的點有 Username/Password/Submit/user/user(Cookie) 這幾個，用戶名一般不能進行注入。
-
看到 User(cookie) 是 Base64 編碼的，解碼后的值和 user 一樣是 youaretheweakestlink 。嘗試對 user 進行 sql 注入，將注入后的字符串進行 Base64 編碼后替換 User(cookie) ，還是不行。
-
查看網頁的HTML源碼，找到被隱藏的表單，可以看到 youaretheweakestlink 的 name 屬性是 user ，它應該就是正確的用戶名，但密碼無法注入，要找到密碼。
密碼在
localhost:8080/WebGoat-5.4/source?source=true，大概靠信息收集吧······
stage2
- 需要獲得全部信用卡號碼，一般通過 sql 注入獲取 database 的信息。
- 查看攔截信息，發現登陸成功后並沒有發送其他請求去獲得 credit card 的數據，所以注意點應該在登陸認證的 request 中。
- 依次對幾個注入點進行檢查，發現對 user（Cookie） 進行注入就可以獲得到所有信用卡信息，但是注意使用的是 Base64 編碼后的信息。
stage3
不同的協議表單獲取頁面，這種表單一般有兩種獲取形式：
- 利用 SQL 從數據庫中讀取
- 利用 cmd 命令行得到
- 先嘗試攔截報文，對 file 字段做 SQL 注入，發現沒有效果。然后進行命令行注入，使用通用命令
ls（webgoat 的 Java 源碼里做了判斷，只有 tcp 有注入漏洞）。 - 注入命令
&& pwd && ls && find -name "webgoat_challenge_guest.jsp"找到目標文件的路徑，注意 Mac 中的指令會有所差別。 - 得到目標文件路徑后，通過注入命令
echo "[payload]" > [target]覆蓋文件內容。