# 十、跨站腳本攻擊 > 作者：Peter Yaworski > 譯者：[飛龍](https://github.com/) > 協議：[CC BY-NC-SA 4.0](http://creativecommons.org/licenses/by-nc-sa/4.0/) ## 描述 跨站腳本，或者 XSS，涉及到站定包含非預期的 JavaScript 腳本代碼，它隨后傳給用于，用戶在瀏覽器中執行了該代碼。它的一個無害示例為： ```js alert('XSS'); ``` 這會調用 JavaScript 函數`alert`，并創建一個簡單的彈出窗口，帶有文本`XSS`。現在，在這本書的前一個版本中，我推薦你在報告中使用這個例子。但是，一個非常成功的黑客告訴我這是個糟糕的例子，因為漏洞的接收者通常沒有意識到這個問題的嚴重性，并且可能由于無害的示例而得到較低的獎金。 所以，考慮到這種情況，使用示例開判斷 XSS 是否存在，但是報告時，考慮漏洞如何影響站點，并解釋它。通過這樣，我并不是告訴廠商什么事 XSS，而是解釋你可以使用它做什么事，來影響他們的站點。 這應該包含識別你報告了何種 XSS，它們包括： + 反射型 XSS：這些攻擊并不是持久的，意思是 XSS 傳遞后通過簡單的請求和響應執行。 + 存儲型 XSS：這些攻擊是持久的，或已保存，之后在頁面加載時執行給無意識的用戶。 + Self XSS：這些攻擊也不是持久的，通常作為戲弄用戶的一部分，使它們自己執行 XSS。 當你搜索漏洞時，你會經常發現，廠商不關心 Self XSS，它們只關心，它們的用戶是否自身存在缺陷，就像反射和存儲 XSS 的例子那樣。但是，這并不是說，你應該完全忽略 Self XSS。 如果你發現了一個場景，其中 Self XSS 可以執行，但是不會存儲，你需要考慮該漏洞是否可以利用，是否有些東西可以結合起來，使其不再是 Self XSS？ 最著名的 XSS 利用示例之一，就是 Samy Kamkar 執行的 MySpace Samy 蠕蟲。在 2005 年 10 月，Samy 利用了一個 MySpace 上的存儲型 XSS 漏洞，允許它上傳 JavaScript 腳本。這個代碼隨后在任何人瀏覽它的 MySpace 主頁時執行，因此使任何 Samy 用戶資料的瀏覽者成為其好友。但是，更多的是，這個代碼也復制其自身到 Samy 新朋友的頁面，所以受感染頁面的瀏覽者使用下面這段話更新了它們的資料頁面：“but most of all, samy is my hero”（最重要的是，Samy 是我的英雄）。 雖然 Samy 的利用并不完全是惡意的，XSS 利用使其能夠盜取用戶、密碼、銀行信息以及其他。雖然具有潛在的影響，修復 XSS 漏洞通常很簡單，只需要軟件開發者在渲染時轉義用戶輸入（就像 HTML 注入那樣）。在攻擊者提交它們的時候，一些站點也會截斷可能的惡意字符。 > 鏈接 > 查看 [OWASP XSS 過濾器繞過速查表](https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet)。 ## 示例 ### 1\. Shopify Wholesale 難度：低 URL：` wholesale.shopify.com ` 報告鏈接：`https://hackerone.com/reports/106293` 報告日期：2015.12.21 獎金：$500 描述： Shopify Wholesale 站點是一個簡單的頁面，擁有不同的操作調用 -- 輸入商品名稱并且點擊“搜索商品”，這里是截圖：  Shopify Wholesale 站點截圖 這里的 XSS 漏洞是你可以找到的最基本的漏洞 - 輸入到搜索框中的文本并沒有轉移，所以任何輸入的 JavaScript 都會執行。這里是漏洞披露中的提交文本：`test’;alert(‘XSS’);’ `。 它生效的原因是，Shopify 接收用戶輸入，執行搜索查詢，當沒有結果返回時，Shopify 會打印一條消息，說該名稱下沒有找到任何商品，之后重新打印出用戶輸入，而沒有任何轉義。因此，提交的 JavaScript 打印到了頁面上，瀏覽器將其解釋為 JavaScript 并執行。 > 重要結論 > 測試任何東西，特別要關注一些場景，其中你所輸入的文本渲染給了你。測試來判斷你是否可以包含 HTML 或者 JavaScript，來觀察站點如何處理它。同時嘗試編碼輸入，就像在 HTML 注入一章中描述的那樣。 > XSS 漏洞并不需要很復雜。這個漏洞是你能找到的最基本的東西 - 一個簡單的輸入文本字段，這個漏洞并不處理用戶輸入。它在 2015 年 12 月 21 日發現，并獲得了 $500 的獎金。它所需要的所有東西，就是黑客的思維。 ### 2\. Shopify 禮品卡購物車 難度：低 URL：` hardware.shopify.com/cart ` 報告鏈接：`https://hackerone.com/reports/95089` 報告日期：2015.10.21 獎金：$500 描述： Shopify 禮品卡站點允許用戶使用 HTML 表單設計它們自己的禮品卡，具體來說，這包括一個上傳輸入框，一些文本框，以及其他。這里是一個截圖：  Shopify 禮品卡表單截圖 這里的 XSS 漏洞在 JavaScript 輸入到了表單圖像名稱字段時出現。在使用 HTML 代理完成之后，會出現一個不錯的簡單任務。所以這里，原始的表單提交會包含： ``` Content-Disposition: form-data; name="properties[Artwork file]" ``` 這會被解釋和修改為： ``` Content-Disposition: form-data; name="properties[Artwork file<img src='test' onm\ ouseover='alert(2)'>]"; ``` > 重要結論 > 這里有兩個東西要注意，這會在尋找 XSS 漏洞時幫助你： > 1. 這里的漏洞實際上并不在文件輸入字段本身 -- 它在字段的名稱屬性中。所以當你尋找 XSS 漏洞的機會時，要記住玩轉所有可用的輸入值。 > 2. 這里的值在通過代理操作之后提交。在一些場景中這是關鍵，其中在任何值實際提交給服務器之前，客戶端（你的瀏覽器）可能存在 JavaScript 來驗證值。 > **實際上，任何時候你看到驗證實時發生在你的瀏覽器中，這都是一個信號，你需要測試這個字段！**開發者可能犯下這個錯誤，一旦這些值提交給了服務器，它們不驗證提交的值是否存在惡意代碼，因為它們認為瀏覽器的 JavaScript 代碼已經在輸入接收之前驗證過了。 ### 3\. Shopify 貨幣格式 難度：低 URL：`SITE.myshopify.com/admin/settings/generalt ` 報告鏈接：`https://hackerone.com/reports/104359` 報告日期：2015.12.9 獎金：$1000 描述： Shopify 的商店設置包含修改貨幣格式的功能。在 12 月 9 日，有報告稱，這些輸入框的值在建立社交媒體頁面時，沒有合理處理。 換句話說，惡意用戶可以建立一個商店，并將貨幣設置修改為下面這個：  Shopify 貨幣格式截圖 之后，用戶就可以開啟社交媒體售賣頻道。報告中的例子是 Fackbook 和 Twitter，以及當用戶點擊這個售賣頻道的選項卡之后，JavaScript 會執行，產生 XSS 漏洞。 > 重要結論 > XSS 漏洞在 JavaScript 文本不安全渲染時產生。文本可能用于站點的多個位置，所以每個位置都應該測試。這里，Shopify 并沒有在商店和收款頁面包含 XSS，因為用戶允許在它們的商店中使用 JavaScript。在考慮字段是否用于外部社交媒體站點之前，很容易把這個漏洞補上。 ### 4\. 雅虎郵件存儲型 XSS 難度：低 URL：Yahoo Mail 報告鏈接：`https://klikki.fi/adv/yahoo.html` 報告日期：2015.12.26 獎金：$10000 描述： 雅虎郵件編輯器允許人們將圖片通過 HTML IMG 標簽嵌入到郵件中。這個漏洞在 HTML IMG 標簽格式錯誤或者無效時出現。 多數 HTML 標簽接受屬性，它是有關 HTML 標簽的額外信息。例如，IMG 標簽接受`src`屬性，指向要渲染的圖像的地址。此外一些屬性是布爾屬性，意思是如果他們存在，他們在 HTML 表現為真值，而當他們被忽略時，他們表現為假值。 對于這個漏洞，Jouko Pynnonen 發現，如果它將布爾屬性添加到 HTML 標簽中，并帶有一個值，雅虎郵件就會移除該值但保留等號。這里是來自`Klikki.fi`的一個例子： ```html <INPUT TYPE="checkbox" CHECKED="hello" NAME="check box"> ``` 這里，輸入標簽可能包含`checked`屬性，表示復選框是否渲染為選中。根據上面描述的歇息，這會變成： ```html <INPUT TYPE="checkbox" CHECKED= NAME="check box"> ``` 要注意 HTML 從擁有`checked`值變成了沒有值但是仍然包含等號。 這看起來是無害的，但是根據 HTML 規范，瀏覽器將這個`CHECKED`看做擁有值`NAME=”check`，并且該`input`標簽有用第三個屬性`box`，它沒有值。這是對于沒有引號的屬性值，因為 HTML 允許零個或多個空格字符在等號周圍。 為了利用它，Jouko 提交了下面的 IMG 標簽： ```html <img ismap='xxx' itemtype='yyy style=width:100%;height:100%;position:fixed;left:0px;top:0px; onmouseover=alert(/XSS/)//'> ``` 雅虎郵件會把它變成： ```html <img ismap=itemtype=yyy style=width:100%;height:100%;position:fixed;left:0px;top:0px; onmouseover=alert(/XSS/)//> ``` 因此，瀏覽器會渲染 IMG 標簽，它占據整個瀏覽器的窗口，當鼠標移到圖片上的時候，會執行 JavaScript。 > 重要結論 > 傳遞格式錯誤或損壞的 HTML 是個不錯的方法，來測試站點如何解析輸入。作為一個黑客，考慮到開發者沒有考慮的東西十分重要。例如，使用常規的圖片標簽，如果你傳遞兩個`src`屬性會怎么樣？它會如何渲染？ ### 5\. Google 圖片搜索 難度：中 URL：` images.google.com ` 報告鏈接：`http://zombiehelp54.blogspot.ca/2015/09/how-i-found-xss-vulnerability-in-google.html` 報告日期：2015.9.12 獎金：未知 描述： 2015 年 9 月，Mahmoud Jamal 使用 Google 圖像來為它的 HackerOne 資料尋找一個圖片。在瀏覽的時候，它注意到 Google 圖片的 URL 中有一些有趣的東西。 ``` http://www.google.com/imgres?imgurl=https://lh3.googleuser.com/... ``` 注意到實際的 URL 中存在 `imgurl`的引用。在鼠標移到縮略圖上的時候，Mahoumd 注意到了錨標簽的`href`屬性包含了相同的 URL。因此，它嘗試將參數改為` javascript:alert(1)`，并且注意到錨標簽的`href`也改為了相同值。 它這個時候非常激動，點擊了鏈接，但是沒有執行 JavaScript，因為 Google URL 改為了別的東西。結果，Google 的代碼在鼠標按下時，通過`onmousedown` JavaScript 回調修改了 URL。 考慮到這個，Mahmoud 決定使用它的鍵盤，嘗試使用 TAB 鍵在頁面上切換。當他來到`View Image`按鈕時，觸發了 JavaScript，產生了 XSS 漏洞。這里是圖片：  Google XSS 漏洞 > 重要結論 > 始終留意這種漏洞。很輕易就能假設，僅僅由于公司太大或者太知名，任何東西都被找到了。但是，公司始終會修改代碼。 > 此外，有大量方法來執行 JavaScript，這里在看到 Google 使用`onmousedown`事件處理器修改值之后，很容易就放棄了。這意味著任何時候使用鼠標點擊了鏈接，值都會改變。 ### 6\. Google Tagmanager 存儲型 XSS 難度：中 URL：`tagmanager.google.com` 報告鏈接：`https://blog.it-securityguard.com/bugbounty-the-5000-google-xss` 報告日期：2014.10.31 獎金：$5000 描述： 2014 年 10 月，Patrik Fehrehbach 在 Google 上發現了存儲型 XSS 漏洞。這個報告的有趣部分是，他如何設法繞過 Google 獲取載荷。 Google Tagmanager 是一個 SEO 工具，使營銷人員添加和更新站點標簽變得容易 -- 包含轉化追蹤、站點分析、重營銷、以及更多。為此，它擁有大量的表單，便于用戶交互。所以，Patrik 以嘗試將 XSS 載荷輸入到表單字段中開始，類似于`#>imgsrc=/ onerror=alert(3)>`。如果接受了，這就會閉合現有的 HTML `>`，之后嘗試加載不存在的圖片，這會執行`onerror` JavaScript，`alert(3)`。 但是，這沒有效果。Google 合理處理了輸入。Patrik 注意到了一個替代方案 -- Google 提供了上傳帶有多個標簽的 JSON 文件的功能。所以，它下載了樣例并上傳： ```json "data": { "name": "#"><img src=/ onerror=alert(3)>", "type": "AUTO_EVENT_VAR", "autoEventVarMacro": { "varType": "HISTORY_NEW_URL_FRAGMENT" } } ``` 這里，你會注意到，標簽的名稱就是他的 XSS 載荷。結果，Google 沒有處理來自上傳文件的輸入，并執行了載荷。 > 重要結論 > 這里有兩個有趣的事情。首先Patrik 發現了替代方案來提供輸入 -- 要留意這個東西，并測試目標提供的所有方法來輸入數據。其次，Google 處理了輸入，但是在渲染時沒有轉義。假設它轉義了 Patrik 的輸入，載荷就不會生效，因為 HTML 會被轉換成無害的字符。 ## 總結 XSS 漏洞對站點開發者展現了真實的風險，并且仍然在站點上流行，通常顯而易見。通常簡單提交 JavaScript `alert`方法的調用，`alert('test')`，你可以檢查輸入字段是否存在漏洞。此外，你可以將它與 HTML 注入組合，并提交 ASCII 編碼的字符來觀察文本是否被渲染和解釋。 在搜索 XSS 漏洞時，這里是要記住的一些事情： 1. 測試任何東西 無論你在瀏覽什么站點以及什么時候瀏覽，總是要保持挖掘！不要覺得站點太大或者太復雜，而沒有漏洞。機會正在注視著你并請求你的測試，就像`wholesale.shopify.com`那樣。Google Tagmanager 存儲型 XSS 漏洞就是尋找替代方案來向站點添加標簽的結果。 2. 漏洞可能存在于任何表單值 例如，Shopify 的禮品卡站點上的漏洞，通過利用和上傳文件相關的名稱字段來時間，并不是實際的文件字段本身。 3. 總是在測試時使用 HTML 代理 當你嘗試提交來自網站自身的惡意值時，當站點的 JavaScript 檢查出你的非法值時，你可能會碰到假陽性。不要浪費你的時間。通過瀏覽器提供合法值，之后使用你的代理修改這些值來執行 JavaScript 并且提交。 > 譯者注：對于所有前端（包括移動和桌面）滲透，都應該這樣。就算不存在 XSS，也有可能挖到繞過和越權漏洞。 4. XSS 漏洞發生在渲染的時候 由于 XSS 在瀏覽器渲染文本時發生，要確保復查了站點的所有地方，其中使用了你的輸入值。逆天家的 JavaScript 可能不會立即渲染，但是會出現在后續的頁面中。這非常麻煩，但是你要留意站點何時過濾輸入，以及轉義輸出。如果是前者，尋找辦法來繞過輸入過濾器，因為開發者可能會犯懶，并且不會轉義渲染的輸入。 5. 測試非預期的值 不要總是提供預期類型的值。當 HTML 雅虎郵件的漏洞被發現時，提供了非預期的 HTML IMG 屬性。要跳出思維定式，思考開發者要尋找什么，并且之后嘗試提供一些不匹配這些預期的東西。這包含尋找新的方式來執行潛在的 JavaScript，例如繞過 Google 圖片的`onmousemove`事件。