WebGoat筆記

(一)WebGoat部署

安裝Tomcat

在官網下載Tomcat 7.0版本的zip包到本地,解壓。(用8.0版登錄不上webgoat)javascript

新建兩個系統變量CATALINA_BASECATALINA_HOME,變量值均爲Tomcat的安裝目錄,例如F:\Webgoat\apache-tomcat-7.0.82。在Path變量中添值%CATALINA_HOME%\lib;%CATALINA_HOME%\binhtml

cmd或powershell移動到安裝目錄下的bin文件夾,執行命令servic.bat installjava

配置WebGoat

下載WebGoat5.4版本的war包,放到Tomcat目錄的webapps子目錄下。web

在conf目錄下的tomcat-users.xml文件中加入如下內容。ajax

<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主頁。sql

(二)General

HTTP基礎

請求報文結構:
shell

請求頭:數據庫

  • If-Modified-Since:說明瀏覽器最後一次收到資源的時間,若是自此以後資源沒有更新,服務器會返回 304 響應指示瀏覽器使用緩存副本;
  • Accept-Encoding:願意接收的內容編碼;
  • Referer:提出當前請求的原始URL;
  • Authorization:爲一種內置的HTTP身份驗證提交證書;

響應報文結構:
apache

響應頭:

  • 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 不變的話頁面信息不會變

  • 多級登錄
  1. 修改參數使已經用過的 TAN(Transaction Authentication Number)驗證碼仍然生效
  2. 修改 user 相關的參數訪問其餘用戶的信息

(六)Buffer Overflows

當計算機向緩衝區內填充數據位數時超過了緩衝區自己的容量,溢出的數據會覆蓋在合法數據上。

  1. 攔截請求後發送到Intruder,將參數 room_no 設爲溢出目標。
  2. 攻擊類型爲 sniper,方案爲 character blocks(大量的字符填充)。
  3. 設置好輸入值,最小、最大值,步長,而後發送payload。

(七)Code Quality

從頁面源碼中找到泄漏的敏感信息,例如在註釋中

(八)Concurrency

線程安全是指一個對象或類的領域在多線程同時使用的時候老是保持有效的狀態。它每每能夠利用併發錯誤,精確地在同一時間、同一個頁面加載另外一個用戶。由於全部的線程共享同一個方法區,而全部的類變量存儲在方法區,多個線程試圖同時使用相同的類變量。

緣由:

  1. Web應用程序能夠同時處理不少HTTP請求

  2. 開發人員常用的變量不是線程安全的​

後果:

用戶利用 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);--

盲注

1) 某些SQL注入是沒有明確返回信息的,只能經過條件的「真」和「假」進行判斷

例:101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );能夠判斷PIN值是否大於1000,以此類推縮小範圍,最終肯定其值

2) 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 可能被跨站攻擊盜取。

例:

  1. 分別用 webgoat 和 aspect 兩個帳號登錄,截取到服務端返回的 cookie 值是AuthCookie=65432ubphcfxAuthCookie=65432udfqtb
  2. 兩個 cookie 值的數字位沒變,英文字符串則是用戶名倒過來後再向後推一位,能夠推測出用戶 alice 的 cookie 是AuthCookie=65432fdjmb
  3. 截取請求並添加推測的 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注入
  1. 使用 WebScarab 的 WebServices 模塊,看到調用的 Web 服務或者 WSDL 歷史文件
  2. WebScarab 將解析 XML 文件,因此能夠選擇調用的操做,而後輸入一個調用的參數值
  3. 在「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

越權登錄,通常有兩種方法:

  1. 經過認證用戶的身份登錄
  2. 利用注入漏洞
  1. 首先嚐試找到注入點,發現輸入可能能夠注入的點有 Username/Password/Submit/user/user(Cookie) 這幾個,用戶名通常不能進行注入。

  2. 看到 User(cookie) 是 Base64 編碼的,解碼後的值和 user 同樣是 youaretheweakestlink 。嘗試對 user 進行 sql 注入,將注入後的字符串進行 Base64 編碼後替換 User(cookie) ,仍是不行。

  3. 查看網頁的HTML源碼,找到被隱藏的表單,能夠看到 youaretheweakestlink 的 name 屬性是 user ,它應該就是正確的用戶名,但密碼沒法注入,要找到密碼。

    密碼在localhost:8080/WebGoat-5.4/source?source=true ,大概靠信息收集吧······

stage2
  1. 須要得到所有信用卡號碼,通常經過 sql 注入獲取 database 的信息。
  2. 查看攔截信息,發現登錄成功後並無發送其餘請求去得到 credit card 的數據,因此注意點應該在登錄認證的 request 中。
  3. 依次對幾個注入點進行檢查,發現對 user(Cookie) 進行注入就能夠得到到全部信用卡信息,可是注意使用的是 Base64 編碼後的信息。
stage3

不一樣的協議表單獲取頁面,這種表單通常有兩種獲取形式:

  1. 利用 SQL 從數據庫中讀取
  2. 利用 cmd 命令行獲得
  1. 先嚐試攔截報文,對 file 字段作 SQL 注入,發現沒有效果。而後進行命令行注入,使用通用命令ls(webgoat 的 Java 源碼裏作了判斷,只有 tcp 有注入漏洞)。
  2. 注入命令&& pwd && ls && find -name "webgoat_challenge_guest.jsp"找到目標文件的路徑,注意 Mac 中的指令會有所差異。
  3. 獲得目標文件路徑後,經過注入命令echo "[payload]" > [target]覆蓋文件內容。
相關文章
相關標籤/搜索