20155209 林虹宇 Exp9 Web安全基础
Exp9 Web安全基礎
XSS
1.Phishing with XSS
跨站腳本攻擊，在表單中輸入超文本代碼
在網頁中形成一個自制的登陸表單，然后將結果反饋到自己的主機上。
攻擊成功
2.Stored XSS Attacks
- 存儲型XSS攻擊
在信息欄中輸入一段js代碼，提交之后，讓點擊這個評論的人觸發xss
結果
3 Reflected XSS Attacks
- 反射型XSS攻擊
- 在enter your three digit access code：處輸入一段簡單的js代碼。
CSRF
4 Cross Site Request Forgery(CSRF)
此題是要寫一個URL誘使其他用戶點擊，從而觸發CSRF攻擊，我們可以以圖片的的形式將URL放進Message框，這時的URL對其他用戶是不可見的，用戶一旦點擊圖片，就會觸發一個CSRF事件
在信息欄中輸入惡意代碼
- 點擊提交
成功
5 CSRF Prompt By-Pass
- 此題包括了兩個請求，一是轉賬請求，二是確認轉賬成功請求，即需要額外傳遞兩個參數給服務器（transferFunds=4000，transferFunds=CONFIRM）
先進入轉賬請求地址
- 點擊confirm
修改語句進入成功地址
SQL
6 Command Injection
在目標主機上執行系統命令，通過火狐瀏覽器下的Firebug對源代碼進行修改，在BackDoors.help旁邊加上"& netstat -an & ipconfig"：
選中修改項，點擊view
出現網絡連接情況
7 Numeric SQL Injection
- 要顯示全部的天氣信息，觀察數據庫語句是要搜索station來顯示相應的信息。
通過修改station選擇的語句，然后讓它沒有選擇，直接全部顯示。
所以修改之后，點擊Columbia提交，實際上提交了一個永真式。
全部顯示，成功。
8 Stage 1:String SQL Injection
這是老師上課演示的題目，知道密碼的輸入長度被限制，所以先修改html代碼。
修改之后輸入’ or 1=1 --密碼
登陸成功。
9 Stage 3:Numeric SQL Injection
課上演示實驗中用到了burpsuite，所以這個實驗中的登陸就先用一下burpsuite。
然后修改html代碼，使提交數據的時候，提交到后臺的員工號變成查找那個工資最高的員工號，然后顯示工資最高的也就是老板的賬號信息。
10 String SQL Injection
這個非常簡單，選擇語句都已經給好了，直接輸入' or 1=1 --
獲取成功
問題回答
- SQL注入攻擊原理，如何防御
- SQL注入即是指web應用程序對用戶輸入數據的合法性沒有判斷，攻擊者可以在web應用程序中事先定義好的查詢語句的結尾上添加額外的SQL語句，以此來實現欺騙數據庫服務器執行非授權的任意查詢，從而進一步得到相應的數據信息。
- 防御：1.檢查變量數據類型和格式，前端js檢查是否包函非法字符。2.過濾特殊符號，對于無法確定固定格式的變量，一定要進行特殊符號過濾或轉義處理。3.綁定變量，使用預編譯語句，MySQL的mysqli驅動提供了預編譯語句的支持，不同的程序語言，都分別有使用預編譯語句的方法。
- XSS攻擊的原理，如何防御
- XSS分三類，存儲型XSS、反射型XSS、DOM-XSS。
存儲型XSS：數據庫中存有的存在XSS攻擊的數據，返回給客戶端。若數據未經過任何轉義。被瀏覽器渲染。就可能導致XSS攻擊。
反射型XSS：將用戶輸入的存在XSS攻擊的數據，發送給后臺，后臺并未對數據進行存儲，也未經過任何過濾，直接返回給客戶端。被瀏覽器渲染。就可能導致XSS攻擊。
DOM-XSS：純粹發生在客戶端的XSS攻擊。 - XSS防御—輸入輸出的過濾和數據轉義
- 輸入：客戶端求情參數：包括用戶輸入，url參數、post參數。
- 輸出：即使在客戶端對用戶的輸入做了過濾、轉義，攻擊者一樣可能，通過截包，轉發等手段，修改你的請求包體。最終還是要在數據輸出的時候做數據轉義。
- CSRF攻擊原理，如何防御
- CSRF全稱 Cross Site Request Forgery, 跨站域請求偽造。
- 攻擊過程：1假設abc用戶登錄銀行的網站進行操作, 同時也訪問了攻擊者預先設置好的網站.2abc點擊了攻擊者網站的某一個鏈接,這個鏈接是http://www.bank.com/xxxx指向銀行,銀行服務器會根據這個鏈接攜帶的參數會進行轉賬操作.3銀行服務器在執行轉賬操作之前會進行SESSION驗證是否登錄, 但是由于abc已經登錄了銀行網站,攻擊者的鏈接也是www.bank.com.所以攻擊的鏈接就會攜帶session id到銀行服務器.4由于session id是正確的,所以銀行會判斷操作是由本人發起的,執行轉賬操作.
- 兩種防御手段
- referer 驗證
- 根據HTTP協議,在http請求頭中包含一個referer的字段,這個字段記錄了該http請求的原地址.通常情況下,-執行轉賬操作的post請求www.bank.com/transfer.php應該是點擊www.bank.com網頁的按鈕來觸發的操作,這個時候轉賬請求的referer應該是www.bank.com.而如果黑客要進行csrf攻擊,只能在自己的網站www.hacker.com上偽造請求.偽造請求的referer是www.hacker.com.所以我們通過對比post請求的referer是不是www.bank.com就可以判斷請求是否合法.
- token 驗證
從上面的樣式可以發現,攻擊者偽造了轉賬的表單,那么網站可以在表單中加入了一個隨機的token來驗證.token隨著其他請求數據一起被提交到服務器.服務器通過驗證token的值來判斷post請求是否合法.由于攻擊者沒有辦法獲取到頁面信息,所以它沒有辦法知道token的值.那么偽造的表單中就沒有該token值.服務器就可以判斷出這個請求是偽造的.
實驗體會
本次實驗是最后一次實驗了，本次實驗借助webgoat實現對web的攻擊，實現對數據庫安全上的攻擊，對html前端代碼的攻擊，也有使用burpsuite對發送的數據包進行截取修改再發送。理解了對網站的一般攻擊步驟，同時也學到了對于不同的攻擊應該如何防范。
轉載于:https://www.cnblogs.com/lhyhahaha/p/9107519.html
總結
以上是生活随笔為你收集整理的20155209 林虹宇 Exp9 Web安全基础的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： OO第三次博客作业---透过代码看设计
- 下一篇： OO第三次博客总结作业