【10.15總結】繞過CSRF的Referer保護

摘要： 今天下午可能要出遠門，所以現在就把總結寫好了。 Write-up地址：[Critical] Bypass CSRF protection on IBM 這個CSRF漏洞存在於IBM的修改郵箱頁面，修改郵箱的地址是 https://www.ibm.com/ibmweb...

今天下午可能要出遠門，所以現在就把總結寫好了。

Write-up地址：ofollow,noindex" target="_blank">[Critical] Bypass CSRF protection on IBM

這個CSRF漏洞存在於IBM的修改郵箱頁面，修改郵箱的地址是

https://www.ibm.com/ibmweb/myibm/account/sendmail?locale=us-en&email=NEW_EMAIL 

所以理論上講，只要修改上面連結中的NEW_EMAIL為自己的郵箱，被攻擊者在登入了自己的IBM賬戶後點擊該連結，就能達到修改被攻擊者郵箱的目的。

但是作者Mohamed Sayed 在嘗試時，發現IBM會檢測請求發出的Referer頭部 ，正常修改郵箱的請求Referer頭部為

https://www.ibm.com/ibmweb/myibm/profile/profile-edit.jsp

作者經過幾個小時的嘗試，發現使用下面的Referer頭部可以成功繞過IBM的驗證

http://my_website/www.ibm.com/ibmweb/myibm/profile/profile-edit.jsp.php 

在測試漏洞時，作者使用了Moakt的臨時郵箱服務生成了一個臨時郵箱地址 作為NEW_EMAIL，在自己的網站上建立檔案profile-edi.jsp.php

<script type="text/javascript">
document.location.href="https://www.ibm.com/ibmweb/myibm/account/sendmail?locale=us-en&email=NEW_EMAIL"
</script>

這樣，只要欺騙被攻擊者訪問該網頁，就可以在自己生成的臨時郵箱裡收到確認修改郵箱的郵件，成功修改被攻擊者IBM賬號的郵箱了。

其實這個漏洞原理很簡單，我之前在看對CSRF介紹的文章時也有看到過驗證Referer的防禦手段，只是真實案例是第一次接觸，所以仍然很有新鮮感。從該案例也可以看出，CSRF可以使用驗證Referer頭部的方式進行防禦，但是網站對Referer的驗證方法仍然可能存在漏洞，需要進行不斷的嘗試 。

今天還看了另外一篇文章DevOops — An XML External Entity (XXE) HackTheBox Walkthrough ，一開始沒明白文章中提到的DevOops是什麼東西，只是覺得可以通過這篇文章瞭解一下滲透測試的簡單流程，後來谷歌了一下，才發現Hack the box是一個線上的滲透測試平臺，感覺還蠻不錯的，註冊需要通過一個小測試，並不難，雖然網上已經有教程了，但我還是遵守規則不說出通過測試的方法，只是一個小tip——看網頁的原始碼。