DVWA學習記錄系列(四)SCRF 跨站偽造請求模組
提示:本文主要針對於SCRF 跨站偽造請求全等級的分析以及相應的破解。
前言
本次主要針對於DVWA當中的跨站偽造請求模組進行學習。主要進行的是dvwa的low、medium、high級別進行破解,由於impossible模組難度過高所以都將不進行impossible的實驗。本次CSRF的high級別將會放至之後的儲存xss漏洞中進行講解。
一、CSRF是什麼?
CSRF,全稱Cross-site request forgery,翻譯過來就是跨站請求偽造,是指利用受害者尚未失效的身份認證資訊(cookie、會話等),誘騙其點選惡意連結或者訪問包含攻擊程式碼的頁面,在受害人不知情的情況下以受害者的身份向(身份認證資訊所對應的)伺服器傳送請求,從而完成非法操作(如轉賬、改密等)。CSRF與XSS最大的區別就在於,CSRF並沒有盜取cookie而是直接利用。
如圖展示:
CSRF攻擊例項
受害者 Bob 在銀行有一筆存款,通過對銀行的網站傳送請求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款轉到 bob2 的賬號下。通常情況下,該請求傳送到網站後,伺服器會先驗證該請求是否來自一個合法的 session,並且該 session 的使用者 Bob 已經成功登陸.
黑客 Mallory 自己在該銀行也有賬戶,他知道上文中的 URL 可以把錢進行轉帳操作。Mallory 可以自己傳送一個請求給銀行:http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是這個請求來自 Mallory 而非 Bob,他不能通過安全認證,因此該請求不會起作用。
這時,Mallory 想到使用 CSRF 的攻擊方式,他先自己做一個網站,在網站中放入如下程式碼: src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”,並且通過廣告等誘使 Bob 來訪問他的網站。當 Bob 訪問該網站時,上述 url 就會從 Bob 的瀏覽器發向銀行,而這個請求會附帶 Bob 瀏覽器中的 cookie 一起發向銀行伺服器。大多數情況下,該請求會失敗,因為他要求 Bob 的認證資訊。但是,如果 Bob 當時恰巧剛訪問他的銀行後不久,他的瀏覽器與銀行網站之間的 session 尚未過期,瀏覽器的 cookie 之中含有 Bob 的認證資訊。這時,悲劇發生了,這個 url 請求就會得到響應,錢將從 Bob 的賬號轉移到 Mallory 的賬號,而 Bob 當時毫不知情。等以後 Bob 發現賬戶錢少了,即使他去銀行查詢日誌,他也只能發現確實有一個來自於他本人的合法請求轉移了資金,沒有任何被攻擊的痕跡。而 Mallory 則可以拿到錢後逍遙法外。
二、實驗注意事項及準備
1)由於CSRF是利用受害者尚未失效的身份認證資訊,因此所有實驗步驟必須在同一瀏覽器中完成,以確保獲得的cookie值一致。
2)Refererd的基礎知識:
是HTTP header的一部分,即是http頭部中的一個資訊,它表示一個來源。例如:在www.google.com中有一個www.baidu.com的連結,則點選該連結後,會傳送一個包,包裡包含的Referer值為:www.google.com。
空Referer情況:
 即表示referer的值為空或不存在referer.因為referer的作用是指示一個請求從哪個連結過來的;所以,當一個請求不由連結的觸發的,自然也無需要指定請求的來源。
3)注意如果,使用程式碼後跳轉至登入頁面或未修改成功的話,需要對程式碼中的URL進行更新,即將頁面新請求的URL複製到程式碼中。
三、實驗步驟
1.low級別
1. 原始碼分析:
由上圖可知,在DVWA中的csrf模組裡主要是針對於改密。且low級別中並無什麼防範措施。
- 實驗開始:
1)首先,在DVWA中調解難度,而後選中CSRF模組,在對應的輸入框中任意輸入一些資訊並點選change,而後便可複製搜尋框中的URL去構造一個惡意的連結。(該連結是由該網站的修改密碼處的URL構成。)
複製的URL如下:
http://127.0.0.1/DVWA-master/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#
上述的URL中在“password_new=”後的內容為你自己想要修改密碼的內容;“password_conf=”後的內容為確認修改密碼的內容。
複製以及修改完成URL後便以及可以進行對密碼的修改了,只要在同一瀏覽器中點選了改URL便可以直接利用CSRF進行修改密碼了。
如圖所示,輸入URL後頁面顯示了密碼已被修改。
當然直接使用這個網址會顯得很長,因此我們可使用縮短網址對其進行縮短
當然直接登入該URL會進行跳轉,因此可使用html程式碼1對其進行掩蓋;又由於我們在修改完成後的資料會直接顯示在URL中,因此可使用html程式碼2,利用post請求進行掩蓋。
程式碼1:
<html>
<head>
</head>
<body>
<img src="http://127.0.0.1/dvwa-master/vulnerabilities/csrf/?password_new=1234&password_conf=1234&Change=Change#" border="0" style="display:none;" />
<h1>404<h1>
<h2>file not found.<h2>
</body>
</html>
效果如下:
此時可登出dvwa,發現預設密碼已被修改。
程式碼2:
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://127.0.0.1/dvwa-master/vulnerabilities/csrf/">
<input type="hidden" name="password_new" value="password" />
<input type="hidden" name="password_conf" value="password" />
<input type="hidden" name="Change" value="Change" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
效果如下:
點選submit後:
進階版:我們可以使用圖片裡包含著超連結,來進行偽裝,使得其更具有誘惑性。
程式碼如下:
<!DOCTYPE html>
<html>
<body>
<a href="http://127.0.0.1/dvwa-master/vulnerabilities/csrf/?password_new=admin&password_conf=admin&Change=Change#">
<img src="http://127.0.0.1/csrfgjxy.jpg" border="0" width="220" height="100">
</a>
</body>
</html>
/*href後的內容為惡意連結;
src後的內容為圖片存在的根路徑。*/
效果圖如下:
點選圖片後,便可直接進行修改…
2)使用burp:
將修改密碼的頁面截斷(截斷的是要點選了change後的頁面),並右擊burp的空白處,選擇Engagment tools,選擇其中的Generate CSRFPOC。 下圖中:上半部分是包的內容,可在params中對密碼修改;下半部分是其burp自動生產的html程式碼,也可直接在html程式碼中對password進行修改,在value後修改。
細心的同學可能發現了,burp生成的HTML程式碼和我們上訴的程式碼2類似。
點選Test In Browser,複製生成的URL,並在瀏覽器中開啟即可。
2.medium級別
1)程式碼分析:
注意上圖畫線的地方:stripos()函式的作用是查詢字串在另一字串第一次出現的位置(不區分大小寫),如未找到則返回false。
本程式碼中的過濾規則是http的referer引數值中必須包含server_name即主機名。並利用stripos進行匹配驗證,從而使得一部分的CSRF無法正常執行。
2)破解的方法1:
當我們在瀏覽器中訪問我們構建的惡意程式碼前,開啟burp截斷進行攔截,並對其進行與正常情況的包進行比較。如圖:
正常情況的包:惡意連結申請的包:
對比可知惡意連結的包確實沒有referer的值,因此程式碼會返回false。
由程式碼可以知道,我們惡意連結不成功的原因是因為請求的包中的referer值沒有包含著server_name。因此我們可以直接對包進行修改。
由上圖可知,自行新增referer值後在傳送的話,是能夠進行修改成功的。
由以上兩圖可以看出,只要referer中包含有其server_name就可以進行修改。
3)破解的方法2:
將之前製作的HTML程式碼放入對方伺服器中,並誘導對方訪問了也可進行CSRF的利用。
程式碼放入伺服器圖:
而後在同一瀏覽器中進行訪問:
此時以及修改成功:
可自行登出,看密碼是否修改。
注:存放的HTML程式碼必須是要有連結進行跳轉的,只能使用之前所訴的程式碼2、3.。
3.high級別
程式碼分析:
新增了token值,防止了csrf進行跨域的請求,很大程度防範了csrf的攻擊。
若對方伺服器存在儲存XSS漏洞,則可用其獲取token值,並利用它進行CSRF利用。
4.imposs級別
程式碼如下:
新增了token機制;新增了要求使用者要輸入當前密碼的機制;新增了PDO防止sql注入。
總結
提示:這裡對文章進行總結:
例如:以上就是今天要講的內容,本文僅僅簡單介紹了pandas的使用,而pandas提供了大量能使我們快速便捷地處理資料的函式和方法。
相關文章
- CSRF 跨站請求偽造學習筆記筆記
- CSRF - 跨站請求偽造
- 密碼學系列之:csrf跨站點請求偽造密碼學
- 跨站請求偽造CSRF攻防
- 理解CSRF(跨站請求偽造)
- [Http] 跨站請求偽造(CSRF)HTTP
- CSRF(跨站請求偽造)簡介
- CSRF跨站請求偽造漏洞分析
- [譯] 跨站請求偽造已死!
- 跨站請求偽造(CSRF)-簡述
- l初識CSRF(跨站請求偽造)
- Django框架:13、csrf跨站請求偽造、auth認證模組及相關用法Django框架
- 跨站請求偽造(CSRF)攻擊原理及預防手段
- SpringSecurity原理解析以及CSRF跨站請求偽造攻擊SpringGse
- Django中如何防範CSRF跨站點請求偽造攻擊Django
- Django csrf跨站請求偽造,校驗,CBV忽略與允許csrf校驗Django
- jenkins v2.229 版本,無法勾選 “跨站請求偽造保護”Jenkins
- Anchor CMS 0.12.7 跨站請求偽造漏洞(CVE-2020-23342)
- SSRF 服務端請求偽造服務端
- java 偽造http請求ip地址JavaHTTP
- 08 CSRF偽造請求攻擊
- php模擬請求(偽造來源和請求ip)PHP
- .NET Core實戰專案之CMS 第十四章 開發篇-防止跨站請求偽造
- Java HttpClient 學習記錄 2 嘗試Get請求JavaHTTPclient
- 伺服器端請求偽造(SSRF)簡介伺服器
- Django框架之csrf跨站請求Django框架
- Django CBV裝飾器 中介軟體 auth模組 CSRF跨站請求Django
- Vue 學習記錄四Vue
- webpack模組化學習記錄Web
- DVWA-檔案包含學習筆記筆記
- Swoft 學習筆記之 request 請求筆記
- csrf解決Ajax請求跨站問題
- Vue3 跨域請求攜帶cookie操作並記錄cookieVue跨域Cookie
- 跨域請求跨域
- 利用SPF記錄缺失傳送偽造郵件
- http協議學習系列(請求頭---Request Headers)HTTP協議Header
- 偽造工作經歷,請止步!!!
- 求學習網站學習網站