web安全_皮卡丘_csrf
csrf源碼分析
pikachu-csrf：
CSRF(get)
allen的住址是nba76，lucy的住址為usa，allen想要把lucy的住址改為nba77.
allen先登陸自己的賬號，去到修改信息的頁面，并修改自己的住址為nba77，發現地址add直接以get請求顯示在url中，其他的信息也是，于是偽造了lucy修改地址的url為：localhost/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=12345678922&add=nba77&email=lucy%40pikachu.com&submit=submit誘導lucy點擊這個鏈接
lucy的原信息：
lucy在登陸的情況下（cookie未失效），不小心點擊了allen偽造的這個鏈接，于是lucy的地址被改成了nba77
代碼分析：
提交修改的請求為GET請求，有固定的變量可以控制，且請求中沒有token驗證參數，也沒有驗證refer
CSRF(post)
情景和上面說的是一樣的，只不過這里是以post提交的數據，allen同樣可以偽造lucy修改地址的請求，http://localhost/pikachu/vul/csrf/csrf_poc.php，誘導lucy點擊
lucy的原信息：
lucy在登陸的情況下（cookie未失效），不小心點擊了allen偽造的鏈接，并且點擊了這個submit按鈕，那么lucy的地址就悄悄被改了。（這里還是只是演示的原理，實際中的偽裝性很高，不可能給你一個submit按鈕讓你按，url也會偽裝的）
lucy發現地址已經被改了
csrf_poc.php
-
小插曲：表單自動提交
本來csrf_poc.php寫的是一個自動提交的表單，代碼如下：
也不用還點擊什么submit按鈕才行了，直接點擊url，自動提交，地址被改。但是發現行不通。我又返回去看了下allen改地址時候的請求包，發現post的數據還有submit=submit一項，而我們自動提交的表單請求包里面沒有submit這個元素，所以改不了，然后我試著在form里添加submit這個元素，添加之后發現無法自動提交了，百度了一下是如果表單里有name為submit的元素，那submit()方法就不能執行，原因是submit被覆蓋了。想深究的還是再去百度一下。代碼分析：
和GET型一樣的原理，只不過這個是post類型的請求，同樣沒有驗證refer，沒有token驗證，沒有防止csrf的措施。
csrf(token)
這個屬于防御了，在修復的時候細講。
csrf修復
1.關鍵操作只接受POST請求
2.驗證碼
csrf攻擊往往是在用戶不知情的情況下構造網絡請求，在關鍵地方設置驗證碼，增加與用戶的互動，可以在一定程度上防止csrf
3.驗證referer
HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求的時候，一般會帶上Referer，告訴服務器該網頁是從哪個頁面鏈接過來的，服務器因此可以獲得一些信息用于處理。通過驗證referer的值，設置referer必須來自同域的網址等，可以判斷請求是合法還是不合法的。但是，由于瀏覽器和服務器的一些問題，這個方法也不是萬無一失的，referer值用戶可以設置成空，由于一些漏洞，referer值可以被篡改。Refere Check 一般用于監控CSRF攻擊的發生，而不用來抵御攻擊
4.token
CSRF攻擊要成功的條件在黑客能夠預測所有的參數從而構造出合法的請求。要抵御 CSRF，關鍵在于在請求中放入黑客所不能偽造的信息，并且該信息不存在于 cookie 之中。可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token，并在服務器端建立一個攔截器來驗證這個 token。token要足夠隨機，不可預測，每次請求成功要更新token，并且最好不要出現在URL中。
我i們可以來看看pikachu csrf(token)一欄：
修改個人信息，抓包，發現url有token參數，并且每次請求會變化
構造之前的請求無法修改，猜測后端有驗證這個token。只有token正確才可以修改。
代碼分析：
修改信息時需驗證$_GET[‘token’]==$_SESSION[‘token’]
set_token函數
csrf挖掘
一般就是看有沒有token參數，測試一下有沒有驗證referer頭等，常結合xss一起利用
總結
以上是生活随笔為你收集整理的web安全_皮卡丘_csrf的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： web安全_暴力破解
- 下一篇： web安全_皮卡丘_xss