從CSRF到用戶信息泄漏，XSS和完整賬戶接管

0x00前言

CSRF漏洞的嚴重性在很大程度上取決於漏洞的位置。有時，錯誤的CSRF保護機制會致使可有可無的問題，例如未經受權的設置更改或清空用戶的購物車。有時，它們會致使更大的問題：用戶信息泄漏，XSS甚至一鍵式賬戶接管。

我在CSRF中遇到了一些致使嚴重安全問題的案例。一般，這些是CSRF和其餘較小的設計缺陷的組合。

0x01 CSRF泄漏用戶信息

CSRF有時會致使信息泄漏。應用程序常常根據用戶偏好發送或公開信息。若是這些設置端點沒有受到CSRF的保護，則能夠爲敏感信息公開鋪平道路。實現基於CSRF的信息泄漏的一種方法是處理這些請求。

例如，我曾經使用過的Web應用程序上的付費服務將每個月的計費電子郵件發送到用戶指定的電子郵件地址。這些電子郵件包括用戶的街道地址，電話號碼和有限的信用卡信息。能夠經過如下請求更改發送這些計費電子郵件的電子郵件地址：

POST /change_billing_email

REQUEST BODY:

email=NEW_EMAIL &csrftok=12345

在此端點上的CSRF驗證已損壞。服務器接受空白令牌，即便csrftok字段爲空，請求也將成功。在使受害者發送如下請求後，全部之後的帳單電子郵件都將發送到ATTACKER_EMAIL（直到受害者注意到未經受權的更改），從而將與該賬戶關聯的街道地址和電話號碼泄露給***者。

POST /change_billing_email

REQUEST BODY:

email=ATTACKER_EMAIL &csrftok=

0x02使用CSRF存儲的Self-XSS

安全團隊幾乎老是將Self-XSS視爲非問題，由於它們難以利用。可是，與CSRF結合XSS使用時，自身XSS一般能夠變成存儲的XSS。

例如，在我遇到的一個金融網站上，用戶能夠爲每一個連接的銀行賬戶建立暱稱。賬戶暱稱字段容易受到XSS的***：該字段上的用戶輸入不進行清理，驗證或轉義。可是，這是隻有受權用戶才能編輯和查看的字段，所以***者沒法直接觸發XSS。

不幸的是，用於更改賬戶暱稱的終結點計算機上也存在CSRF錯誤。該應用程序未正確驗證CSRF令牌的存在，所以僅在請求中省略令牌參數將繞過CSRF保護。例如：

POST /change_account_nickname

REQUEST BODY:

nickname=<XSS PAYLOAD> &csrftok=WRONG_TOKEN

該請求將失敗。

POST /change_account_nickname

REQUEST BODY:

nickname=<XSS PAYLOAD>

雖然此請求將成功更改用戶的賬戶暱稱，並存儲XSS有效負載。下次用戶登陸賬戶並查看其儀表板時，將觸發XSS。

0x03使用CSRF接管用戶賬戶

這些是我發現的一些最簡單的賬戶接管。這些狀況也很多見。當賬戶驗證功能（如建立密碼，更改密碼，更改電子郵件地址或重置密碼）中存在CSRF問題時，就會發生賬戶接管問題。

例如，這是我在客戶端的Web應用程序中發現的錯誤。

該網絡應用程序容許社交媒體註冊。用戶經過社交媒體註冊後，他們能夠選擇經過如下請求設置密碼：

POST /password_change

REQUEST BODY:

oldpassword= &newpassword=XXXXX &csrftok=12345

因爲用戶經過其社交媒體賬戶註冊，所以不須要舊密碼便可設置新密碼。所以，若是CSRF保護在此終結點上失敗，***者將可以爲經過其社交媒體賬戶註冊但未設置密碼的任何人設置密碼。

不幸的是，這正是在此特定端點上發生的事情。應用程序沒法正確驗證CSRF令牌，並接受一個空值做爲csrftok參數。所以，從本質上講，如下請求會將任何人（還沒有設置密碼）的密碼設置爲ATTACKER_PASS。

POST /password_change

REQUEST BODY:

oldpassword= &newpassword=ATTACKER_PASS &csrftok=

如今，***者所須要作的就是將該請求嵌入到網站用戶常常訪問的頁面上，而且她能夠將訪問這些頁面的任何用戶的密碼自動分配給ATTACKER_PASS。以後，***者可使用新分配的密碼自由做爲任何受害者登陸。

0x04總結

CSRF很是廣泛，很是容易利用。雖然我遇到的大多數CSRF都是低嚴重性問題，但有時對關鍵端點進行監督可能會致使嚴重後果。

若是您是開發人員，請特別注意部署在關鍵端點上的CSRF保護機制。