建站
咨詢
售后
建站咨詢
新聞中心
說到跨站資源監(jiān)控，首先會聯(lián)想到『Content Security Policy』。既然 CSP 好用，我們何必自己再搞一套呢。那就先來吐槽下 CSP 的缺陷。
站在用戶的角度思考問題，與客戶深入溝通，找到港北網(wǎng)站設(shè)計與港北網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站設(shè)計、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名申請、網(wǎng)站空間、企業(yè)郵箱。業(yè)務(wù)覆蓋港北地區(qū)。
目前的 CSP
日志不詳細
用過 CSP 的都很郁悶，上報的只有違規(guī)的站點名，卻沒有具體路徑。這是缺陷，還是特意的設(shè)計？
顯然，CSP 是為安全定制的，里面的規(guī)范自然要嚴格制定，否則就會帶來新的安全問題。如果支持詳細路徑的上報，那又會引出什么問題？
由于 CSP 會上報所有的請求，甚至包括重定向的，因此可以用來探測重定向后的地址。假如已登錄的用戶訪問 login.xx.com 會重定向到 xx.com/username，那么攻擊者設(shè)計一個只允許重定向前的規(guī)則的頁面，用戶訪問后，重定向后的 URL 就會當做違規(guī)地址上報給攻擊者，這其中就包括了用戶名。
如果支持詳細路徑的上報，這簡直就是災難，就用來探測的用戶隱私信息了。事實上目前只上報主機名，都能進行一些利用，例如這篇 Using Content-Security-Policy for Evil。
不過新的規(guī)范總是在改進，未來也許只上報重定向前的 URL。但在這之前，我們只能接受這些雞肋的上報日志。
規(guī)則不靈活
CSP 目前只支持白名單列表，這多少有些死板。
更糟的是，不同規(guī)則之間無法繼承和共享。例如默認有個 default-src 規(guī)則，但其他的規(guī)則會覆蓋它，而不是繼承它。這就導致各個規(guī)則之間，出現(xiàn)很多的重復，使得整個字符串變的冗長。
無法和頁面交互
CSP 的監(jiān)控和上報，是在瀏覽器后臺自動處理的，沒有提供一個事件供頁面進行交互。
這樣就只能使用統(tǒng)一方式強制處理了，而無法交給頁面腳本，更好的來自定義處理。
上報方式不可控
如果處理方式有多種選擇，那么統(tǒng)一處理也無可厚非。
但事實上 CSP 的上報方式及格式，沒有任何可選余地。只能使用 POST + JSON 的方式提交，并且其中的字段十分累贅，甚至把規(guī)則里的白名單列表也發(fā)上來了。
此外，也無法設(shè)定一個緩存時間，控制重復上報的間隔。在配置白名單遺漏時，會出現(xiàn)大量的誤報，嚴重消耗資源。
浪費帶寬
在較新的 Chrome 里，能夠使用 meta 標簽在前端頁面定義 CSP 規(guī)則，但其他瀏覽器目前仍不支持。
為了能夠統(tǒng)一，大多仍使用 HTTP 頭部輸入的方式。由于規(guī)則通常都很長，導致每次頁面訪問，都會額外增加數(shù)百字節(jié)。
維護繁瑣
如果是通過 Web 服務(wù)開啟的，那么每次調(diào)整策略，都得修改配置甚至重啟服務(wù)，很是麻煩。
兼容性不高
目前只有高版本的瀏覽器支持，而 IE 系列的則幾乎都沒能很好的支持。
如果某些攻擊只爭對低版本的瀏覽器，那么很有可能出現(xiàn)大量遺漏。
模擬的 CSP
原理
事實上在 CSP 出現(xiàn)的好幾年前，就有一個能夠監(jiān)控跨站資源的方案，下面就來分享下。
寫過 JS 的都知道，如果需要給大量元素監(jiān)聽事件，無需對每個元素上都進行綁定，只要監(jiān)聽它們的容器即可。當具體的事件冒泡到容器上，通過 event.target 即可獲知是哪個元素產(chǎn)生的。
腳本、圖片、框架等元素加載完成時，都會產(chǎn)生 onload 事件；而所有元素都位于『文檔』這個頂級容器。因此我們監(jiān)聽 document 的 onload 事件，即可獲知所有加載資源的元素。
不過 onload 這個事件比較特殊，無法通過冒泡的方式來監(jiān)聽。但在 DOM-3 標準模型里，事件還有一個『捕獲』的概念，這也是為什么 addEventListener 有第三個參數(shù)的原因。
我們通過事件捕獲機制，將其拿下，從而監(jiān)控文檔級別的全局 onload 事件。
類似的，如果資源加載失敗，會觸發(fā) onerror 事件。我們也可同時將其捕獲，跟蹤那些暫時不可用的跨站資源。
優(yōu)勢
通過腳本的方式，就可以更靈活的處理問題了。規(guī)則的黑白名單，上報方式、格式等等，都可以自己來定義。最重要的是，我們能夠獲得詳細的違規(guī) URL 了！
相比后端配置，前端腳本更新維護起來容易的多。而且得益于瀏覽器緩存，無需每次更新配置，節(jié)省很多資源。
增強
也許你已經(jīng)發(fā)現(xiàn)了，這只能實現(xiàn) CSP 的 Report-Only 功能，根本無法進行攔截。而且其他的內(nèi)聯(lián)事件、網(wǎng)絡(luò)通信等也沒有涉及。
不過本文的主題已經(jīng)說了，只是監(jiān)控跨站資源而已，并不攔截。事實上，如果能夠做到及時發(fā)現(xiàn)問題，就很不錯了。
如果非得通過 JS 來實現(xiàn)攔截功能，可以參考之前的『XSS 前端防火墻系列』：
-
內(nèi)聯(lián)事件攔截
-
跨站資源攔截
-
網(wǎng)絡(luò)通信攔截
雖然可以更嚴格的防護，但實現(xiàn)起來更臃腫，性能開銷也更大。要是攔截了正常的業(yè)務(wù)功能，造成的損失會更大。
而使用如何這個小技巧，只需幾行代碼即可實現(xiàn)，性能消耗忽略不計。
缺陷
當然，那么簡單的方案肯定無法全面。
由于我們只監(jiān)聽文檔容器，有些還未加入到文檔的元素產(chǎn)生的事件，我們就無法捕獲到了。最典型的就是：
new Image().src = '...'雖然創(chuàng)建的 HTMLImageElement 對象具有 onload 事件，但是此時還只是一個離屏元素，事件就無法對外傳播了。
如果非得解決，只能通過函數(shù)鉤子的方式監(jiān)控 URL。
此外，IE9 以下的瀏覽器不支持 DOM-3，而 attachEvent 是無法設(shè)置捕獲的，因此我們還需一個后備方案。畢竟國內(nèi)低版本 IE 用戶仍有不少，即使能實現(xiàn)部分功能，也勝于無。
#p#
后備
事實上，即使主流瀏覽器，有些特殊元素并沒有 onload 事件，例如 Flash 插件。
為了彌補這些不足，同時盡可能保持簡單高效，我們使用定時輪詢的方式，對特定元素進行掃描。這里使用一個大家都知道，但未必都清楚的方法：document.getElementsByTagName。
這個功能都知道，但返回的類型或許很少琢磨。他返回的并不是一個 Array，也不是 NodeList，而是 HTMLCollection。
在 W3C 規(guī)范描述中，有一個顯眼的詞 『live』，已經(jīng)道出了這個接口的獨特之處——它是一個動態(tài)的集合，能隨著容器內(nèi)元素的增減而變化。
因此，我們事先映射出文檔容器內(nèi)的元素，之后即可隨時查詢集合了。
除了 SCRIPT，我們還可以監(jiān)控所有存在風險隱患的元素，例如：EMBED，OBJECT，IFRAME 等等。這樣即使是低版本的 IE 用戶，也能參與預警上報了，比起完全沒有好的多。
當然，這種簡單方法也很容易被繞過。如果腳本刪除了自身元素，那么我們就無法跟蹤到了。而腳本一旦運行就已在內(nèi)存里，即使元素節(jié)點被移除，仍然能繼續(xù)運行。
不過，對于一般的情況也足夠應對了。通常運行商的廣告劫持，大多都很落后。即使要進行后期對抗，也可以利用之前的前端防火墻，使用嚴格的方案。
擴展信息
見過 CSP 日志的大多都會很困惑，出現(xiàn)的這些違規(guī)資源，究竟位于頁面何處。由于沒有確切的細節(jié)，給排查工作帶來很大困難。
畢竟，絕大多數(shù)的上報問題，都是無法復現(xiàn)的。它們要么是運行商的廣告，或者是瀏覽器插件。難很通過這些日志，來定位問題所在。
既然如今使用自己的腳本來實現(xiàn)，理應帶上一些有意義的信息。除了資源類型和詳細 URL，我們還需要一個能夠定位問題所在的參數(shù)——DOM 路徑。
將每層元素的 #id 和 .class 跟隨標簽名，得到一個標準的 CSS 選擇器。通過它，即可非常容易的定位到違規(guī)元素，同時也能用于統(tǒng)計和分析。
例如出現(xiàn)頂級元素就是 SCRIPT 的，顯然這是一個被插入到 之外的腳本，很有可能就是運營商注入的廣告腳本。
例如出現(xiàn) HTML > BODY > ... > DIV.editor-post > SCRIPT 這樣帖子容器里的腳本，那么極有可能是出現(xiàn) XSS 了。正常情況下，用戶內(nèi)容區(qū)域并不會出現(xiàn)腳本元素。
通過詳細的上報日志不斷學習，后端即可越來越精準的分析出問題所在。
而這些，目前的 CSP 難以實現(xiàn)。
上報方式
吸取 CSP 報告的不足之處，我們使用更靈活的方式。
對于運營商廣告那樣的跨站資源，反復上報同樣的信息，是毫無意義的，只會浪費帶寬資源。對于同一類警告，一定時間內(nèi)上報一次就后夠了。
利用 URL、DOM 路徑等信息，可以更容易的將日志進行客戶端去重。通過本地存儲的記錄，就不必每次都上報了，在本地記錄違規(guī)的次數(shù)即可。
對于不嚴重的警告，本地也可以累計到一定的數(shù)量再上報。這樣多條日志一次發(fā)送，即可大幅減輕后端壓力。甚至還可以考慮壓縮內(nèi)容，節(jié)省網(wǎng)絡(luò)帶寬。
只有讓前端進行負載維護，才不至于大規(guī)模部署的場合下，接收端被海量的誤報日志拖垮。
總結(jié)
盡管 CSP 的初衷很美好，但到如今，仍只是能用，并沒有做到好用。因此，實際面臨的問題，還是得靠自己來解決。
當然，標準的制定本來就是受益于大眾的，我們也希望 CSP 標準能發(fā)展的越來越好用。
文章標題：巧妙利用onload事件的特殊性來監(jiān)控跨站資源
路徑分享：http://m.5511xx.com/article/dphoeos.html
