當前位置:
首頁 > 最新 > Web安全攻防靶場之WebGoat–1

Web安全攻防靶場之WebGoat–1

概述

WebGoat是OWASP組織研製出的用於進行web漏洞實驗的Java靶場程序,用來說明web應用中存在的安全漏洞。WebGoat運行在帶有java虛擬機的平台之上,當前提供的訓練課程有30多個,其中包括:跨站點腳本攻擊(XSS)、訪問控制、線程安全、操作隱藏欄位、操縱參數、弱會話cookie、SQL盲注、數字型SQL注入、字元串型SQL注入、web服務、Open Authentication失效、危險的HTML注釋等等。WebGoat提供了一系列web安全學習的教程,某些課程也給出了視頻演示,指導用戶利用這些漏洞進行攻擊。

GitHub地址為https://github.com/WebGoat/WebGoat

部署後首頁截圖

目前WebGoat分為三類,Lesson、Challenges/CTF、WebWolf。

其中Lesson為課程,每個課程中包括漏洞描述,成因,以及練習,

上圖中紅色的點就是練習內容,如果練習通過了,紅點就變成綠色的。

Challenges/CTF 就是常規的一些解題內容。

WebWolf是一套含有漏洞的應用,用來進行漏洞練習。


部署

在github上WebGoat的release版本庫里https://github.com/WebGoat/WebGoat/releases 下載release版本。

https://github.com/WebGoat/WebGoat/releases/download/v8.0.0.M17/webgoat-server-8.0.0.M17.jar

https://github.com/WebGoat/WebGoat/releases/download/v8.0.0.M17/webwolf-8.0.0.M17.jar

下載完成後到下載目錄,執行命令

這樣就能打開WebGoat了。

同時,官方提供了另外一個含有漏洞的應用WebWolf來,執行命令

都執行成功後,就可以通過通過鏈接http://127.0.0.1:8080/WebGoat/ 訪問WebGoat,通過鏈接http://127.0.0.1:9090/login 訪問WebWolf。


使用

首先需要注入一個賬號,然後登陸後,按照WebGoat的側邊順序一項一項進行測試。


WebGoat is a deliberately insecure application that allows interested developers just like you to test vulnerabilities commonly found in Java-based applications that use common and popular open source components.

Now, while we in no way condone causing intentional harm to any animal, goat or otherwise, we think learning everything you can about security vulnerabilities is essential to understanding just what happens when even a small bit of unintended code gets into your applications.

What better way to do that than with your very own scapegoat?

Feel free to do what you will with him. Hack, poke, prod and if it makes you feel better, scare him until your heart』s content. Go ahead, and hack the goat. We promise he likes it.

Thanks for your interest!


利用在WebGoat上註冊的賬號登錄http://127.0.0.1:9090/WebWolf/home 。

裡面的兩個assignment只要是為了說明釣魚攻擊。簡單測試即可


本課介紹了理解瀏覽器和Web應用程序之間數據傳輸以及如何使用HTTP代理捕獲請求/響應的基礎知識。

Stage 2

就是一個簡單的發送包程序

Stage 3

此assignment的主要目的是讓學習者學習如何看HTTP數據包,從下圖可以看到,該題目使用的數據提方式為POST,裡面有參數magic_num,具體指請查看數據包內容。

Chrome具體操作為,在頁面空白處點擊右鍵,選擇,然後在新打開的欄目中點擊,然後在頁面上點擊,然後選擇,查看具體包內容。


這裡說明如何使用代理捕獲流量,我們使用BurpSuite。

打開BurpSuite,進入下圖紅框界面,設置代理端戶口為127.0.0.1:9999

打開chrome瀏覽器,安裝插件,打開設置,新建情景模式,代理埠9999。

選擇代理burp。

設置Burpsuite代理為打開。

然後進行本單元測試。

點擊Submit後,向抓取的包添加,修改POST提交方式為GET,同時修改參數的值為,完成測試。


這裡是注入攻擊的課程,包括sql注入和XXE(XML External Entity attack,外部實體引用攻擊)。


了解什麼是sql注入攻擊,sql注入攻擊包括字元型和數字型。

字元型注入

數字型注入

攻擊方式

拼接到sql語句後的形式

Stage7

輸入,然後就獲取了所有信息。

Stage8

輸入,然後就獲取了所有信息。


sql特殊符號

sql語句

Stage3

union注入,該問題需要注意首先要union的列數一致,同時還需要對應列的類型一致。

Stage5

登錄代碼都寫成這樣了,目前還沒想出來怎麼使用tom進行登錄。

但是在註冊代碼處存在問題,在查詢用戶是否註冊時傳入的沒有進行任何過濾,會導致盲注漏洞。

可以這樣進行測試,我已經註冊了一個admin賬戶,再次註冊會報用戶已註冊。

然後使用一個這樣去註冊,會發現永遠都可以註冊成功,具體的原因是這樣,的用戶名構造成的查詢用戶是否註冊語句會成為

可以看到,這樣的sql語句是永遠也查不出結果的,所以就一直提示未註冊,這也就證明了這裡存在sql盲注漏洞。

可以用sqlmap跑一下看看結果。


防禦sql注入,其實就是session,參數綁定,存儲過程這樣的注入。

上面說的方式也不是能夠絕對的進行sql注入防禦,只是減輕。

如參數綁定方式可以使用下面方式繞過。

通過使用語句可以將後的orderExpression表達式中添加select語句。

Stage8 question

這道題目看題目源碼就是一個case注入。

目前使用寫在column中是可以執行的,對應的sql語句為

由於對hsqldb語法不了解,後面的注入過程無法再繼續了。


全稱XML External Entity attack,XML外部實體攻擊。

一個XML實體允許定義標籤,當解析XML文檔時,標籤將被內容取代。 通常有三種類型的實體:

* 內部實體

* 外部實體

* 參數實體。

一個實體必須在文檔類型定義(Document Type Definition,DTD)中創建,一個例子:

在xml後面的部分里,調用實體; 解析器將用實體中定義的值替換它。而XXE攻擊就是因為實體內容可以被攻擊者控制而導致的一種攻擊。

用上面的XML做一個具體解釋,第一行表明該文檔符合XML1.0,第二行說明該文檔使用author辭彙表,author是根元素。關鍵字SYSTEM 解析器將根據給出的URL尋找DTD,關鍵字PUBLIC 根據URI尋找DTD。

DTD的四種標記聲明

ELEMENT xml元素類型聲明

ATTLIST 特定元素類型可設置的屬性&屬性的允許值聲明

ENTITY 可重用的內容聲明

NOTATION 不要解析的外部內容的格式聲明。

Stage 3

只是最簡單的一個引用外部實體,下圖添加評論comment並提交後。

會得到下圖的數據包,可以看到,評論是通過xml格式傳到後台的,所以就可以進行xxe測試了。

按照如下數據包進行發送,就可以獲取填入的文件內容。在comment欄位中調用了DTD中定義的實體test,而test實體又是獲取文件/etc/passwd的內容,由於題目並沒有回顯,而是同時返回包的內容來進行判斷是否成功,當再次刷新頁面的時候,就可以看到/etc/passwd的內容在評論里顯示出來了。

Stage 4

和上一題目類似,不過此題目採用的傳輸數據包是json格式。

因為json的xxe攻擊方式其實就是測試當HTTP頭的屬性是否能夠正確接受,只要能夠接受,就有很大概率存在xxe,從下圖可以看到,該題目雖然用json能夠正常傳到後台,但是使用xml傳輸也是能夠正常執行的。

看下源碼

源碼對進行了判斷,然後根據不同類型來進行不同的解析操作。所以修改了HTTP包頭的屬性後,和Stage 3的poc一樣就可以xxe了。

xxe 的 ddos

當xml中的dtd包含這樣的形式

當XML解析器載入此文檔時,它會看到它包含一個根元素「lolz」,其中包含文本「&lol9;」。 但是,「&lol9;」 是一個定義的實體,擴展為包含十個「&lol8;」的字元串字元串。 每個「&lol8;」 字元串是一個定義的實體,擴展為十個「&lol7;」 字元串等等。 所有的實體擴展都經過處理後,這個小於1KB的xml將擴展到3GB。

盲XXE

在某些情況下,xxe沒有輸出,因為儘管您的攻擊可能已經發揮作用,但該欄位並未反映在頁面的輸出中。 或者您嘗試讀取的資源包含導致解析器失敗的非法XML字元。 用Stage 7這個例子說明一下。

Stage 7

首先,我們包含一個外部dtd,叫做,此dtd我用python啟動SimpleHTTPSever進行訪問。

下面就是這個的具體內容,可以看到這段xml的意思是,先訪問一個secret.txt文件,將內容放在對象file中,然後將file放在鏈接中發送出去,這樣,就可以把一個沒有回顯的xxe做到讀出內容。

具體效果如下:


身份驗證缺陷


許可權繞過

Stage 2

本題目其實很簡單,問題出在進行參數判斷時,沒有對參數名進行有效的處理,只判斷了安全問題個數一致,就可以通過。具體代碼如下。

攻擊截圖

更換後


jwt是一種防止用戶修改本地存儲數據的數據結構。

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.

JSON Web Token is used to carry information related to the identity and characteristics (claims) of a client. This "container" is signed by the server in order to avoid that a client tamper it in order to change, for example, the identity or any characteristics (example: change the role from simple user to admin or change the client login). This token is created during authentication (is provided in case of successful authentication) and is verified by the server before any processing. It is used by an application to allow a client to present a token representing his "identity card" (container with all user information about him) to server and allow the server to verify the validity and integrity of the token in a secure way, all of this in a stateless and portable approach (portable in the way that client and server technologies can be different including also the transport channel even if HTTP is the most often used)

jwt具體內容為https://jwt.io/introduction/

一個JWT token的樣式如下:

這個token是由三部分組成的base64字元串,解碼後樣式如下:

使用方式

Stage 4

此題目的是要求使用admin許可權的賬戶進行vote的reset操作,但是默認的幾個用戶都不是admin許可權。

將jwt token進行解密

基於此,則用下面一段代碼生成一個新的jwt token,讓用戶為admin許可權。

更改發包中的內容,即可通過此題目。

注意,此題目生成token的代碼中,需要知道jwt token生成的鹽是什麼值,才能夠保證jwt token生成後的簽名值的正確性。

Stage 5

此題目和Stage 4類似,是讓對一段jwt token進行解碼並修改username值後再次提交,如果能夠通過驗證,則通過此題目。

直接給出代碼

成功通過

Stage 7

通常有兩種令牌:訪問令牌和刷新令牌。 訪問令牌用於對伺服器進行API調用。 訪問令牌的使用壽命有限,這就是刷新令牌的來源。一旦訪問令牌不再有效,可以通過呈現刷新令牌向伺服器發送請求以獲得新的訪問令牌。 刷新令牌可以過期,但其壽命要長得多。

從可以找到付款鏈接中存在Tom的jwt token,但是使用後發現token已過期,說明需要刷新該token才能再次使用。

此題目後台代碼

所以此題的思路應該是,首先找到用Jerry賬戶登錄,獲取刷新token,然後使用刷新token和Tom的訪問token進行訪問令牌的刷新,獲取到新的訪問令牌後,進行購物車買單,繞過許可權。

獲取Jerry的刷新令牌。

使用Jerry的刷新令牌獲取Tom的訪問令牌。

使用Tom的訪問令牌進行買單操作,題目完成。

Stage 8

本題目的目的是讓用戶能夠仿冒Tom的Token來刪除他的微博。

從下面源碼進行分析,可以看到JWT的簽名鹽是從資料庫中讀取的,但是獲取資料庫鹽的值的地方傳入的參數並沒有進行任何的過濾,這樣就可以使用注入來偽造一個JWT的簽名鹽,從而達到偽造目的。

分析一下原始Token的內容。

也看當前的用戶是Jerry,首先我們將用戶名改為Tom,然後修改第一部分中kid的值為,即當查詢表jwt_keys時,又將輸入參數kid的值webgoat_key返回給jwt token當做簽名鹽使用。構造代碼。

按照下圖發送包,題目完成。


密碼重置

Stage 2 question

這道題目好像有問題,webwolf里接收不到郵件。

Stage 4

由於設置的安全問題太簡單,最簡單的一個暴力破解就行了,具體看圖。

同時官網給出了一個鏈接,http://goodsecurityquestions.com/ ,裡面說明了如何設置一個好的安全問題。

Stage 5 question

在此題目中,WebGoat給出了一個密碼重置鏈接的開發建議:

在創建密碼重置鏈接時,您需要確保:

這是一個隨機令牌的獨特鏈接

它只能使用一次

該鏈接僅適用於一個小時

使用隨機令牌發送鏈接意味著攻擊者無法通過開始阻止用戶而對您的網站啟動簡單的DOS攻擊。 該鏈接不應再多使用一次,這使得無法再次更改密碼。 超時是限制攻擊窗口所必需的,通過鏈接為攻擊者提供了很多可能性。

這道題目同樣接受不到郵件,跳過。


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 全球大搜羅 的精彩文章:

椅子:明朝官椅上的許願骨
她的釣魚遊戲開始啦……

TAG:全球大搜羅 |