DVWA之CSRF

時間 2019-11-17

標籤 dvwa csrf 欄目系統安全简体版

原文原文鏈接

CSRF：跨站請求僞造攻擊

Security：Low 級別分析javascript

核心代碼html

輸入數據，以便Burp代理得到請求參數java

這裏能夠將第一行拿出來進行構造連接，瀏覽器

http://202.100.10.129/dvwa/vulnerabilities/brute/?username=111&password=111&Login HTTP/1.1服務器

或者利用burp編寫Poc，當咱們在Burp中抓到包後，點擊右鍵編寫Poccookie

當用戶觸發這個請求後，函數

密碼就會被修改爲111，固然，這樣子用戶能看到的話，用戶就知道了本身的密碼被修改，明顯很不現實。那麼如何在用戶不知情的狀況下進行修改密碼的攻擊呢？ui

咱們能夠採起構造攻擊頁面的方式：spa

在真實狀況下，這種方法須要事先在公網上上傳一個攻擊頁面，誘導用戶去訪問這個頁面，這樣才能在用戶不知情的狀況下進行攻擊。3d

沒有公網服務器的狀況下，能夠在本地環境假設這個攻擊頁面的服務器，這裏採用Kali做爲這個攻擊頁面的服務器。

啓動Apache服務

當用戶訪問到這個頁面後，會顯示不存在，通常狀況下，用戶都會選擇關掉這個頁面，沒有人去選擇查看源碼進行分析，這是不現實的，而此時用戶的密碼已經被咱們修改爲功，

當用戶退出後，下次再登陸的時候就會發現已經沒法登陸了。由於此時密碼已經被修改了。

Security：Medium級別分析

核心代碼:

相關函數說明

int eregi(string pattern, string string)

檢查string中是否含有pattern（不區分大小寫），若是有返回True，反之False。

能夠看到，Medium級別的代碼檢查了保留變量 HTTP_REFERER（http包頭的Referer參數的值，表示來源地址）中是否包含SERVER_NAME（http包頭的Host參數，及要訪問的主機名，即202.100.10.129），但願經過這種機制抵禦CSRF攻擊

漏洞利用：

既然服務器進行了過濾，經過分析源代碼能夠獲得，它要求http包頭的Referer參數的值中必須包含主機名。

方法一：Burpsuite抓包進行修改後再提交給服務器

Ctrl+R發送到repeater，將主機名添加到Referer的後面

預覽能夠看到，密碼已經在用戶不知情的狀況下被修改

方法二：

將攻擊頁面名稱改成用戶主機名202.100.10.129.html （攻擊頁面放在攻擊者本身的服務器裏，202.100.10.130/202.100.10.129html），當用戶不當心點到這個頁面時，會自動執行如下腳本，用途就是更改密碼。

用戶通常看到404就會關掉，固然地址是能夠換成比較隱蔽的形式。

Burpsuite截到的包

Security：High級別分析

核心代碼

能夠看到，該級別加入了Anti-CSRF token方法來防範CSRF攻擊，同時每次隨機生成一個token，當用戶提交的時候，服務器端會檢查token值是否正確，很好的起到了防範做用。很差攻破。不過照樣仍是能夠被利用，能夠發現High級別的反CSRF機制，最關鍵的地方就是要獲取token，利用受害者的cookie去修改密碼的頁面獲取關鍵的token。咱們能夠試着去構造一個攻擊頁面，將其放置在攻擊者的服務器，引誘受害者訪問，從而完成CSRF攻擊，下面是代碼。

<script type="text/javascript">

function attack()

{

document.getElementsByName('user_token')[0].value=document.getElementById("hack").contentWindow.document.getElementsByName('user_token')[0].value;

document.getElementById("transfer").submit();

}

</script>

<iframe src="http://192.168.153.130/dvwa/vulnerabilities/csrf" id="hack" border="0" style="display:none;">

</iframe>

<body onload="attack()">

<form method="GET" id="transfer" action="http://192.168.153.130/dvwa/vulnerabilities/csrf">

<input type="hidden" name="password_new" value="password">

<input type="hidden" name="password_conf" value="password">

<input type="hidden" name="user_token" value="">

<input type="hidden" name="Change" value="Change">

</form>

</body>

當受害者不當心點擊這個頁面後，該網頁中的腳本會發生請求，偷偷去訪問修改密碼的頁面，獲取頁面的Token值，並向服務器發起修改密碼的請求。

PS：不過受到同源策略的限制，這種請求是沒法正常執行的。簡單來講，就是當用戶訪問被攻擊服務器A時，被默默的要求去請求B服務器上的攻擊腳本，這怎麼能夠，吃着本身碗裏的還想吃別人碗裏的，瀏覽器不容許這種行爲，除非別人主動從他碗裏給你夾肉過來。。。。。

故只有將攻擊頁面（將本身的肉放在別人的碗裏，不給你也得給你，皮一下，就是這麼個道理。）放在被攻擊者的服務器上，讓被攻擊服務器去請求位於本身服務器上的資源，這固然是沒有問題的了。

Security：Impossible級別

核心代碼：

能夠看到， Impossible 級別的代碼利用PDO 技術防護SQL 注入，至於防禦CSRF ，則要求用戶輸入原始密碼（簡單粗暴），攻擊者在不知道原始密碼的狀況下，不管如何都沒法進行CSRF 攻擊。

注意：CSRF最關鍵的是利用受害者的cookie向服務器發送僞造請求，因此若是受害者以前用Chrome瀏覽器登陸的這個系統，而用搜狗瀏覽器點擊這個連接，攻擊是不會觸發的，由於搜狗瀏覽器並不能利用Chrome瀏覽器的cookie。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。