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