XSS Case Study

Prologue

這是針對我在前公司處理過的電商網站攻擊案例所做的概略整理。以下列出的攻擊方式不一定會單獨出現,多半都是混合使用

Cases

URL Encoded Attack

攻擊者向會員發送一段訊息,訊息裡夾帶一段類似網址的字串 www&#46really-bad&#46com

當會員讀取到這段訊息,&#46 被瀏覽器解碼變成 . 之後,顯示出來的就會是 www.really-bad.com 這樣完整的網址

其中還有一種變體是針對 RFC 3490 的實作所進行的攻擊方式:

Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop).

在網址中插入會被識別為 . 的字元。例如 www。really-bad。com 這個字串,對瀏覽器來說,就等效於 www.really-bad.com

Deceptive Phishing

攻擊者向會員發送一段訊息,內容含有與公司網址極為相似的假網址:

您好,我已經下標了,麻煩確認一下這款是否還有現貨?

https://conpany.com/goods/12345

最好可以一起合併結帳,過兩天就去匯款,請核對謝謝!

其中 conpany.com 並不是屬於公司的網址,正確的網址應該是 company.com 才對

而會員點擊假網址之後,就會來到攻擊者仿造的公司會員登入頁面。就算會員檢查登入頁面的網址,也只會看到像是 https://conpany.com/member/login 這樣,與真正的登入網址極為相似的假網址

如果沒有非常仔細地確認的話,連公司內部的開發人員都很容易上當

Code Injection

這是我在處理時,出現次數最多的攻擊方式。多半是在 <form> 中輸入攻擊字串,然後在會員接收到 <form> 送出的內容後觸發攻擊。舉例來說:

  • 將自訂商品分類的名稱命名為 <script src=//hack.u>,當會員開啟商店首頁時就會觸發,被重新導向到攻擊者的網頁
  • 攻擊者在發送站內訊息時,插入 <iframe src=//devil.c&#99;> 字串。當會員開啟站內訊息時,因為網頁介面上預設會顯示引用文字的關係,所以在瀏覽器讀到攻擊字串後,會員就會被重新導向到攻擊者的網頁
  • 結帳時,在購買人的 email 欄位輸入 <SCRIPT SRC=bad/url></SCRIPT> 字串。在會員查看結帳明細時就會觸發攻擊,被重新導向到攻擊者的網頁

Control Character Injection

如果在黑名單中只設定了像是 www.malicious.com/hack.html 這種格式的 URL 規則的話,攻擊者可以在字串中塞入 null byte 來繞過黑名單。例如 %00www.%00malicious.%00com/%00hack.%00html

而且這段 URL 仍然可以被點擊,或做為重新導向的目標

其他像是 &#x0200d; 等 zero width character 也有相同的效果

Web Parameter Tampering

https://dummyurl.com/vulnerable.php?page=4%3Ciframe%20src=http://hack/you%3E 這種格式的 URL 就是一個典型的例子

當會員開啟 https://dummyurl.com/vulnerable.php 時,如果後端沒檢查 $_GET['page'] 的內容,就直接把它顯示在頁面上的話,瀏覽器在讀到 %3Ciframe%20src=https://hack/you%3E這一列時,就會跳轉到攻擊者的網頁

Summary

簡單來說:

  1. 不要相信使用者輸入的 任何 內容
  2. 所有輸入的值 必須且只能 是你預期的值

不過在實際開發時,往往有所取捨,所以最後還是要看情況來決定實際的作法