是否可以通过用户脚本检测页面修改？

如果你有一个网站，你可以以某种方式找出访问者是否正在用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

是否可以通过用户脚本检测页面修改？

回答

相关问题