利用 onload 事件監控跨站資源

用過 CSP 的都很鬱悶，上報的只有違規的站點名，卻沒有具體路徑。這是缺陷，仍是特地的設計？

顯然，CSP 是爲安全定製的，裏面的規範天然要嚴格制定，不然就會帶來新的安全問題。若是支持詳細路徑的上報，那又會引出什麼問題？

因爲 CSP 會上報全部的請求，甚至包括重定向的，所以能夠用來探測重定向後的地址。假如已登陸的用戶訪問 login.xx.com 會重定向到 xx.com/username，那麼攻擊者設計一個只容許重定向前的規則的頁面，用戶訪問後，重定向後的 URL 就會當作違規地址上報給攻擊者，這其中就包括了用戶名。

若是支持詳細路徑的上報，這簡直就是災難，就用來探測的用戶隱私信息了。事實上目前只上報主機名，都能進行一些利用，例如這篇 Using Content-Security-Policy for Evil。

不過新的規範老是在改進，將來也許只上報重定向前的 URL。但在這以前，咱們只能接受這些雞肋的上報日誌。

規則不靈活

CSP 目前只支持白名單列表，這多少有些死板。

更糟的是，不一樣規則之間沒法繼承和共享。例如默認有個 default-src 規則，但其餘的規則會覆蓋它，而不是繼承它。這就致使各個規則之間，出現不少的重複，使得整個字符串變的冗長。

沒法和頁面交互

CSP 的監控和上報，是在瀏覽器後臺自動處理的，沒有提供一個事件供頁面進行交互。

這樣就只能使用統一方式強制處理了，而沒法交給頁面腳本，更好的來自定義處理。

上報方式不可控

若是處理方式有多種選擇，那麼統一處理也無可厚非。

但事實上 CSP 的上報方式及格式，沒有任何可選餘地。只能使用 POST + JSON 的方式提交，而且其中的字段十分累贅，甚至把規則裏的白名單列表也發上來了。

此外，也沒法設定一個緩存時間，控制重複上報的間隔。在配置白名單遺漏時，會出現大量的誤報，嚴重消耗資源。

浪費帶寬

在較新的 Chrome 裏，可以使用 meta 標籤在前端頁面定義 CSP 規則，但其餘瀏覽器目前仍不支持。

爲了可以統一，大多仍使用 HTTP 頭部輸入的方式。因爲規則一般都很長，致使每次頁面訪問，都會額外增長數百字節。

維護繁瑣

若是是經過 Web 服務開啓的，那麼每次調整策略，都得修改配置甚至重啓服務，非常麻煩。

兼容性不高

目前只有高版本的瀏覽器支持，而 IE 系列的則幾乎都沒能很好的支持。

若是某些攻擊只爭對低版本的瀏覽器，那麼頗有可能出現大量遺漏。

模擬的 CSP

原理

事實上在 CSP 出現的好幾年前，就有一個可以監控跨站資源的方案，下面就來分享下。

寫過 JS 的都知道，若是須要給大量元素監聽事件，無需對每一個元素上都進行綁定，只要監聽它們的容器便可。當具體的事件冒泡到容器上，經過 event.target 便可獲知是哪一個元素產生的。

腳本、圖片、框架等元素加載完成時，都會產生 onload 事件；而全部元素都位於『文檔』這個頂級容器。所以咱們監聽 document 的 onload 事件，便可獲知全部加載資源的元素。

不過 onload 這個事件比較特殊，沒法經過冒泡的方式來監聽。但在 DOM-3 標準模型裏，事件還有一個『捕獲』的概念，這也是爲何 addEventListener 有第三個參數的緣由。