系列博文

信安小白，說明白滲透測驗及資訊安全
信安小白，一篇博文講明白暴力破解和SQL注入
信安小白，一篇博文講明白上傳漏洞——獲得shop靶機的Webshell
信安小白，一篇博文講明白存盤型、反射型XSS漏洞
信安小白，一篇博文講明白CSRF攻擊和防御

前言

如果沒有XSS漏洞，還能否盜用用戶的身份(cookies)呢？

信安小白，一篇博文講明白XSS攻擊與防御

DVWA實驗目標： 修改用戶登錄密碼，
??我們日常生活中，碰到修改密碼時，需要填入原密碼，才能再修改密碼，或者填入密保問題再修改，還有的是使用手機驗證碼驗證后才能修改，這些措施的目的是確認用戶本人才能修改自己的密碼，但如果是 攻擊者想冒充他人，能否請求修改密碼呢？會有漏洞出現嗎？

一、CSRF是什么

??跨站請求偽造（Cross-site request forgery），通常縮寫為 CSRF 或者 XSRF，盜用（偽造）了用戶身份，以用戶名義發送惡意請求，這種惡意請求被服務器當做正常請求執行，簡單來說就是：攻擊者盜用了你的身份，以你的名義發送惡意請求，
csrf

1.如何判斷存在CSRF漏洞？

??我們的目的是冒充用戶修改密碼，因此修改請求只能是用戶（或者帶著用戶cookie）發出，從XSS漏已知，攻擊者可以引誘用戶點擊惡意鏈接進入惡意網站，發送請求讓攻擊者獲取用戶身份，因此不用擔心用戶能否跨站發出修改請求，跨站請求的核心是：構造請求url，因此我們必須要知道目標網站是如何修改密碼的需要提供什么資訊引數才能修改，
??通過實驗，我們發現在實驗“CSRF”的頁面中將管理員密碼改為123，可以得到url:
http://192.168.3.37/dvwa/vulnerabilities/csrf/？password_new=123&password_conf=123&Change=Change#
同時，我們還需要驗證：是否能跨站使用此url的相關修改密碼引數來進行修改，如果可以，那就是存在CSRF漏洞，但往往不可以，只有用戶自己提交修改密碼引數（帶著用戶的合法cookie)，服務器才認可，因此綜上所述，攻擊者如何讓用戶自己提交引數呢？

在已經登錄進入DVWA的狀態下，新打開網頁，這里的ip地址是目標網站服務器的ip地址：

<img src="http://192.168.1.*/dvwa/vulnerabilities/csrf/?password_new=hack&password_conf=hack&Change=Change#"border="0" style="display:none;"/>
<h1>404<h1>
<h2>file not found.<h2>

CSRF攻擊滿足的必要條件：

用戶登錄網站A是登陸狀態，生成cookie
網站存在CSRF漏洞，服務器對提交引數沒有任何驗證（只要帶cookie就可以通過）
用戶在不登出網站A的情況下，可以訪問攻擊者惡意網站
用戶在不知情的情況下，訪問惡意網站，跨站向A請求（跨站請求偽造）

2. 分析中級CSRF原始碼加固機制

if( isset( $_GET[ 'Change' ] ) )
// Checks to see where the request came from
if( eregi( $_SERVER[ 'SERVER_NAME' ], $_SERVER[ 'HTTP_REFERER' ] ) )

函式說明：
int eregi(string pattern, string string)
??檢查string中是否含有pattern（不區分大小寫），如果有回傳True，反之False，Medium級別的代碼檢查了http包頭的Referer引數的值（表示來源地址）HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求時，一般會帶上Referer，告訴服務器我是從哪個頁面鏈接過來的，如果是別的網站鏈接，就不能驗證成功，

Burp抓包查看：
用戶自己登錄:
Host: 192.168.1.120
Referer: http://192.168.1.120/dvwa/vulnerabilities/csrf

訪問攻擊者網頁跨站連接：
Host: 192.168.1.120
Referer: http://192.168.1.121/csrf.html

跨站請求的referer與用戶自己的referer完全不一樣，ip地址是關鍵字，但可以把檔案名（例如:csrf.php）改成網站的ip地址，有了關鍵字就可以繞過了，

3. 分析高級CSRF原始碼加固機制

if( isset( $_GET[ 'Change' ] ) )
// Check Anti-CSRF token
checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );

??High級別的代碼加入了Anti-CSRF token機制，用戶每次訪問改密頁面時，服務器會回傳一個隨機的token（令牌），向服務器發起請求時，需要提交token引數，而服務器在收到請求時，會優先檢查token，只有token正確，才會處理客戶端的請求，用戶每次重繪會重新重繪token，

4. 分析Impossible級CSRF原始碼加固機制

if( isset( $_GET[ 'Change' ] ) )
// Check Anti-CSRF token
checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );
$pass_curr = $_GET[ 'password_current' ];

??Impossible級別不僅檢查token，還要求輸入原密碼，

二、XSS和CSRF比較

XSS：
??用戶過分信任網站，放任來自瀏覽器地址欄代表的那個網站代碼在自己本地任意執行，如果沒有瀏覽器的安全機制限制，xss代碼可以在用戶瀏覽器為所欲為；
CSRF：
??網站過分信任用戶，放任來自所謂通過訪問控制機制的代表合法用戶（不管合不合法，只要持有cookie）的請求執行網站的某個特定功能，

三、CSRF攻擊案例

修改密保問題：攻擊者利用漏洞，修改密保問題為自己的，從而進入修改頁面修改密碼，
修改識訓地址
洗掉博客
百度Hi之CSRF蠕蟲攻擊
??百度用戶中心短訊息功能和百度空間、百度貼吧等產品相互關聯，用戶可以給指定百度ID用戶發送短訊息，在百度空間用互為好友的情況下，發送短訊息將沒有任何限制
CSRF和XSS組合（最常見）

??我們登陸網站后會看到資料填寫頁面，空間里的資訊只能用戶自己看見，如果填寫的資訊存在xss漏洞，沒有進行過濾，一些XSS腳本就會被服務器存盤并存盤在自己的個人資料庫中，而這些資訊只對個人空間有效，并不能影響別人，同時用戶也不會自己提交XSS腳本到資料庫中去，因此，在這種情況下，這里的服務器很可能不會進行XSS過濾， 我們稱這種情況稱之為Self-XSS，
?? 問：這里怎樣在用戶登錄的狀態下，讓用戶自己上傳腳本到服務器呢？
?? 答：如果這個頁面還存在CSRF漏洞，就偽造用戶身份可以利用CSRF漏洞，讓用戶跨站請求，讓用戶在修改資訊的同時提交惡意js腳本，此時服務器就能將js腳本存在個人資料庫中了，下一次用戶登錄頁面時，服務器就能讓腳本發給用戶，用戶執行腳本就把自己資訊發送給攻擊者了，

四、CSRF防御

是源于WEB的隱式身份驗證機制
??WEB的身份驗證機制雖然可以保證一個請求是來自于某個用戶的瀏覽器，CSRF攻擊但卻無法保證該請求是用戶批準發送的

CSRF防御

驗證碼
??用戶在表單中填寫一個圖片上的隨機字串
使用token校驗
??對于CSRF檢查的請求（一般是POST請求），服務端會分配一個token，在這次session的有效時間之內，客戶端每次請求都發送token到服務器，服務器驗證token是否相同，相同則放行，否則回傳錯誤資訊
手機短信驗證等

實驗

實驗目的：
1）撰寫釣魚網頁，修改用戶名和密碼，
2）提出防御方案，

查看DVWA更改密碼的格式

url：password_new和password_conf自擬

# url是 目標網站服務器的ip地址+網頁路徑+新的密碼引數+重復的密碼
http://192.168.163.128/DVWA-1.9/vulnerabilities/csrf/?password_new=xxx&password_conf=xxx&Change=Change

準備惡意網站腳本，引誘用戶點擊：ip地址為DVWA的ip地址，也就是要提交網站的ip地址，我這里是自己的ip地址，

<img src="http://192.168.163.128/DVWA-1.9/vulnerabilities/csrf/？password_new=xxx&password_conf=xxx&Change=Change#" border="0" style="display:none;"/> 
<h1>404<h1> 
<h2>file not found.<h2>