是否可以通過用戶腳本檢測頁面修改？

如果你有一個網站，你可以以某種方式找出訪問者是否正在用JavaScript腳本修改你的網站？是否可以通過用戶腳本檢測頁面修改？

2013-02-07 Outback

你想要什麼樣的修改，來檢測和哪種瀏覽器？ –

簡答：是的。 ......較長的回答：以用戶無法阻止的方式來檢測mod是非常困難的。 ......理論上，用戶可以阻止任何網站的行爲（除了黑暗）。 –

總之：EEEEEEK！不要這樣做！相反，決定什麼需要被守衛，並且後衛那。不惜一切代價避免輪詢（定期檢查）。尤其要避免對任何事情進行定期的嚴格檢查。

不是每一個變化都可以追蹤。大部分變化都非常難以追蹤，因爲可以改變的東西太多了。

可以檢測DOM（新節點，刪除的節點，已更改的屬性）的更改。另一個答案建議定期檢查innerHTML，但最好使用mutation observers（由Firefox，Chrome支持）或較舊的突變事件（DOMSubtreeModified等）（支持因事件而異）。

除了通過比較每個單一方法和手動屬性（eeeek）之外，不能可靠地檢測標準方法的更改。這包括需要引用萬噸的對象包括，比如說，Array.prototype.splice（和Array和Array.prototype爲好，當然），並定期運行重腳本。但是，這不是用戶腳本通常所做的。

輸入的狀態是屬性而不是屬性。這意味着文檔HTML 不會更改。如果狀態被腳本更改，則change事件也不會觸發。再次，唯一的解決方案是輪詢手動（eeek）每個輸入。

沒有可靠的方法來檢測是否已附加事件處理程序。首先，你需要警惕的onX屬性（第2號），檢測到addEventListener（EK）任何呼叫（不跳閘段＃2支票），您的圖書館（jQuery.bind和其他幾個人檢測到相應的方法的任何調用）。

~~一個件事，對你有利的發揮，也可能是唯一一個：用戶腳本在頁面加載（從來沒有更早）運行，因此你有充足的時間來準備你的防禦。~~not even that plays in your favor（感謝Brock Adams注意和鏈接）

你可以通過用你自己的（ek）替代它來檢測標準方法。有很多方法需要用這種方式進行測試（eek），有些是通過瀏覽器進行的，有些是通過框架進行的。事實上，IE瀏覽器（甚至可以指示firefox，謝謝@Brock）不會讓你觸摸DOM類的原型爲「eek」添加另一個「e」或者兩個。一些方法只能通過方法調用（返回值，回調參數）獲得的事實添加了另一個「e」或兩個，總共爲「eeeek」。對整個window進行爬網的想法將被安全異常和不可捕獲的安全異常所挫敗。也就是說，除非您不使用iFrame，並且您不在iFrame內。

即使你檢測每一個方法調用，DOM可以通過寫innerHTML改變。 Firefox和Chrome支持Mutation Observers，所以你可以使用這些。

即使你檢測每一個方法調用預先存在的方法，聽聽突變，大部分屬性由既不反射，所以你需要的每一個對象，以及觀看所有屬性。祈禱某人不會使用您永遠不會猜到的密鑰添加非可枚舉屬性。順便提一句，這也會捕獲DOM突變。在ES6中，可以觀察對象的屬性集。我不確定是否可以將setter附加到ES5中的現有對象屬性（同時遵守ES3語法）。輪詢每個屬性是eeeek。

當然，你應該讓自己腳本，做一些變化。工作流程將設置一個標誌（不能從全局範圍訪問！）「我是合法的」，做你的工作，並清除國旗 - 記得也側重所有的回調。方法觀察者然後將檢查設置的標誌。財產看門狗將很難檢測到更改是否有效，但可以從每個合法更改的腳本中通知他們（手動;再次確保用戶腳本無法看到該通知流）。 Eeek。

有一個完全不同的問題，我起初並沒有意識到：用戶腳本在頁面加載時運行，但它們也可以創建iFrame。這並不是完全不可能的（但仍不太可能）（現在爲），腳本會：1）檢測你的腳本攔截器，2）從軌道覈對頁面（你不能阻止document.body.innerHTML =，至少不會嚴重篡改document.body）， 3）插入一個帶有原始URL的單個iframe（防止雙重加載服務器端？）和4）在您的保護被加載之前有足夠的時間來處理空的iframe。

而且，看到the duplicate found by Brock Adams，這表明我沒有想到的，應該做一些其他檢查。

來源

2013-02-07 08:12:19

修改Re：'用戶腳本在頁面加載時運行（不會更早），所以你有足夠的時間來準備你的防禦。「......不，每個支持腳本的瀏覽器都支持[在任何頁面加載之前啓動。]（http：// developercript.chrome.com/extensions/content_scripts.html#run_at）userscript可以覆蓋原型並隱藏所有類型的觀察者和安全措施。在Firefox和Opera的情況下，在執行之前有選擇性地阻止或編輯頁面的JavaScript並不難。在Chrome中並不容易。另外，Firefox對象可以被凍結，所以頁面不能覆蓋它們。 –

@BrockAdams將其劃掉了，謝謝 –

Re：「相反，決定需要保護什麼，並且保護那個。」+1。不信任客戶。始終在服務器端驗證，消毒和交叉引用。最後，如果數據是好的（並且遊戲規則沒有違揹他人的危害），那麼無論客戶做什麼或者他做了什麼都沒有關係。（然而，我懷疑OP是一個擔心對策的編劇。） –

如果你沒有自己的腳本，改變的東西，你冷比較document.body.innerHTML和document.head.innerHTL與它是什麼。

當您在腳本中更改DOM時，您可以更新值以與之比較。使用setInterval定期進行比較。

來源

2013-02-07 07:06:40 HMR

並非所有更改都可以通過此方式檢測到 –

像哪些更改不會被檢測到？我能想到的唯一事情就是調整窗口大小。任何JS改變都會對DOM的屬性/值或DOM/DOM元素進行一些修改。這會改變innerHTML – HMR

對不起，你是對的。輸入文本值，用戶定義的屬性在更改時不顯示，並且可能更多。 – HMR

是否可以通過用戶腳本檢測頁面修改？

回答

相關問題