聊兩句XSS(跨站指令碼攻擊)

貪婪的君子發表於2020-12-27

XSS(跨站指令碼攻擊),聊兩句,五毛的。

XSS的危害:

  • 竊取Cookie,盜用使用者身份資訊

這玩意兒是大多數XSS的目標,也好解決,可以先治個標,直接設定HttpOnly=true ,即不允許客戶端指令碼訪問,設定完成後,通過js去讀取cookie,你會發現document.cookie 無法讀取到被標識為HttpOnly的Cookie內容了。

  • 配合其他漏洞,如CSRF(跨站請求偽造)

這個其實就沒那麼好解決了,因為XSS利用使用者身份構造的請求其實對於服務端來說是合法的。比如說我們在B站上傳了一條視訊,發現沒幾個人點贊,於是動了歪心思,開啟控制檯找到了投幣點讚的介面,然後拿到了對應的請求引數。自己構造了一條投幣請求,然後誘導其他人點選含有這個指令碼的頁面為我們的視訊投幣,這樣就完成了一套攻擊流程。

不用嘗試了,沒用的。別問我怎麼知道的 =。=。

要是沒做校驗的話,那這就是一個高危漏洞,還傳啥視訊啊,趕緊發郵件給阿B領賞金去啊。

  • 廣告

只要能發起XSS,我就能往頁面裡插廣告,啥許可權都不要,但是能引發這個問題的原因主要有兩個。

  1. XSS。
  2. 使用者自己安裝外部指令碼。

使用外部指令碼一定要保證指令碼來源的可信性,指令碼的安全性。如果指令碼是惡意的,那麼他所能做的可就不只是彈彈廣告這麼簡單了,替換個按鈕,誘導點選釣魚頁面,替換某一條搜尋結果,這都是可能的。

XSS掃描及防範

XSS風險有些是可以通過code review發現的,比如:

let result = document.getElementById('test');
result.innerHTML = await getInfo();

這段程式碼很容易看到風險位置——innerHTML ,如果後端返回的資料中包含惡意的程式碼片段,那麼就能夠被攻擊。所以在使用Vue和React框架時,需要評估是否真的需要使用v-htmldangerouslySetInnerHTML 功能,在前端的render(渲染)階段就避免innerHTMLouterHTML [1]

如果不使用框架,那就避免直接使用innerHTML 就好了。

至於review時無法發現的風險,那就交給掃描器吧。

防範XSS,除了少使用、不使用innerHTML 外,還可以設定嚴格的CSP[2],限制使用者的輸入長度。

XSS是一個安全問題,它不只是前端的職責,這也是所有RD和QA的職責。

前端過濾使用者輸入後發給後端,後端如果不做處理存入資料庫,那麼這就是一個攻擊點:直接抓前端的包,重新組裝一下引數,發給後端,完成儲存型XSS第一步,使用者再訪問這部分內容,就完成了一次XSS。

QA的總能搞出來一些奇奇怪怪的payload(亦稱測試用例),這些可能都是RD未能考慮到的方面。

附一段白名單過濾使用者輸入的程式碼,點選GitHub檢視。


  1. 如何防止xss攻擊 ↩︎

  2. 內容安全策略 ↩︎

相關文章