看我如何利用開發人員所犯的小錯誤來盜取各種tokens

如果網站允許載入外部圖片的話，我就可以通過下面這種方法來添加一張外部圖片然後記錄referrer頭的數據

但很不幸這種方法在這裡行不通。除此之外，這裡也不允許使用標籤，可能是伺服器出錯了吧。不過也無所謂，反正我也不打算通過這個標籤來竊取token，因為這種方法所需要的用戶交互太多了。

我已經將該漏洞通過HackerOne上報給了Shopify，感興趣的同學可以查看相關的漏洞報告。

2.通過各種小漏洞竊取Facebook的訪問令牌

對於這種類型的漏洞，我所能找出了例子已經數不勝數了，其中的一個我已經在HackerOne上披露了相關細節，感興趣的同學可以查閱一下，也許你可以從中了解到這種漏洞的運行機制。

在此之前，我已經在Facebook上找到了很多影響很小或者根本沒有影響的安全漏洞，但如果我們將這些漏洞全部串起來形成一個漏洞鏈，那麼我們將有可能竊取到Facebook提供給kitcrm.com的Facebook用戶訪問令牌（當前用戶）。

a.在kitcrm.com中，用戶通過shopify賬號完成註冊，此時他們商店中的產品將會出現在Priority Products區域中。

b.當用戶嘗試編輯一款Priority Products時，提交的請求中將包含產品圖片的URL地址，其中url以POST參數的形式出現。

c.用戶可以隨意設置產品圖片，比如說，用戶可以將產品圖片（url）設為http://evil.com/，而系統將會接受修改並將其作為產品圖片的url。

d.不會對認證令牌的有效性進行驗證，所以網站的登錄節點則存在一個CSRF漏洞（其實也沒多大影響）。

e.kitcrm.com的用戶可以通過訪問https://www.kitcrm.com/users/auth/shopify?shop=zh5409.myshopify.com來完成自動驗證，訪問之後用戶將會被重定向到https://zh5409.myshopify.com/admin/oauth/authorize?client_id=1333a1b83ccdf7a7…..，接下來用戶又會被重定向回kitcrm.com並完成登錄驗證。

f.Kitcrm的Facebook認證應用的redirect_uri配置將允許重定向到下面這種形式的地址：

https://www.kitcrm.com/

現在將我剛才所說的東西串聯起來，我們就能夠竊取到用戶的Facebook訪問令牌了：

1. 
   

   攻擊者註冊一個shopify商店，然後用它來註冊一個kitcrm.com賬號；



2. 
   

   註冊成功之後，將他的Priority Product產品圖片url修改為https://evil.com/log_token.php；



3. 
   

   接下來，想辦法欺騙用戶訪問一個特殊製作的HTML頁面；



4. 
   

   通過CSRF將目標用戶登錄進攻擊者的商店；



5. 
   

   通過CSRF將目標用戶登錄進kitcrm.com；



6. 
   

   將目標用戶重定向至https://www.facebook.com/v2.7/dialog/oauth?client_id=372033192897621&redirect_uri=https%3A%2F%2Fwww.kitcrm.com%2Fseller/onboarding/1&response_type....，這條鏈接又會將他重定向回https://www.kitcrm.com/seller/onboarding/1?code=[fb_token]



7. 
   

   當用戶從Facebook重定向到kitcrm.com之後，系統會向https://evil.com/log_token.php發送一個請求，而返回的referrer頭重則包含了我們所要的東西；



8. 
   

   現在，攻擊者就可以將得到的token保存在自己的後台伺服器中，然後用它來登錄目標用戶的Facebook賬號了。
   

PoC代碼

Steal.html

log_token.php

3.SillyXSS與賬號接管

註：首先我要聲明，這是一個非公開的測試項目，因此我不會在這裡提到任何有關廠商的內容。

什麼？你沒聽說過Silly XSS?好吧…在我看來，SillyXSS指的仍然是一個XSS漏洞，但這個漏洞只能作用於過時的瀏覽器中；不過還有一種定義，即指的是那種需要大量用戶交互才可以利用的XSS漏洞。

這一次測試過程中出現的XSS存在於一個隱藏的標籤中，所以我打算通過下面這種方法注入我的payload：

但標籤的「<」卻被網站替換掉了（str_replace($payload,』<』 ,』』)），所以這種方法不可行。

Portswigger上的一位網友曾寫過一篇關於「隱藏域中的XSS漏洞「的文章，感興趣的同學可以參考一下【

傳送門

所以我還是得靠自己，我得想辦法設計一種新的方法來利用這種隱藏域中的XSS漏洞。比如說下面這種方法：

但這樣還是不行，因為瀏覽器無法給出類型為hidden的input。所以我得把type屬性的值修改為除了「hidden」之外的其他值。例如：

x"type=text onmouseover=alert(1) x

但瀏覽器會忽略我所添加的這種多重屬性，並只會接受第一個屬性值。

當時我在尋找XSS漏洞利用的方法時所測試的其中一個地方是x」 type=imagesrc=http://aaaa.com x，而這種參數形式可以向[http://aaaa.com](http://aaaa.com)發送一個請求，而且type類型仍然是「hidden」！！但是當我用Firefox測試同樣的內容時，瀏覽器卻沒有發出請求，所以我的第一反應就是將該問題上報給Google，但隨後我便發現這個漏洞已經有人報告過了，不過Google對此卻不以為然。

綜上所述，我們可以通過目標站點來請求任何外部資源，而此時網站支持用戶通過第三方服務（例如微信）來完成登錄的話，那麼我所要做的就是將redirect_uri參數設置為[https://vulnerable/path/to/xss/payload](https://vulnerable/path/to/xss/payload)，當用戶通過第三方服務完成了網站登錄之後，他將會被重定向到[https://vulnerable/path/to/xss/payload](https://vulnerable/path/to/xss/payload)，而我在payload中注入的HTML會將我們所要的數據從（微信）後台返回到我的伺服器中，接下來我就可以用這些數據來登錄目標用戶的賬號了。

結束語

如果有什麼不懂的地方，歡迎大家通過Twitter與我聯繫（

@Zombiehelp54

*參考來源：

seekurity