第一

Question

我的问题有两个方面。首先，沙盒模型如何工作，如何影响用户脚本，从网页和用户脚本角度可以访问/看到的内容，以及如果使用其他沙盒模型会影响页面是否能够注意到您的脚本是否被注入页面。第二，如何将脚本注入到页面中，并且页面可以检测到它？

第一

据我所见，当您使用@grant none时，沙箱被禁用，您将可以访问该网页及其javascript。如果您对javascript和/或DOM进行任何更改，则该页面可能会检测到它。

我的理解是，如果您使用@grant unsafeWindow，则脚本将被隔离在其自己的js上下文中，您对window所做的任何操作都不会显示在网页上，但是您可以访问该网页和JavaScript通过unsafeWindow。您将可以定期访问DOM，例如document返回常规页面文档，而不需要您说unsafeWindow.document。显然，您对DOM或页面js上下文所做的任何更改（例如unsafeWindow.foo = 'bar';）仍然可以检测到。之所以成为unsafe的原因不是因为是否被检测到，而是因为您可以在此模式下（可能无法在常规模式下授予特权）GM_*功能，从而使不受信任的页面访问特权，这意味着任何功能的@grant GM_*都将隔离js上下文，除非您@grant unsafeWindow）

，否则您将无法访问页面的js上下文。

第二

如何将脚本注入页面？网页是否可能注意到用户脚本注入（假设用户脚本修改了页面上的NOTHING）。

例如，如果使用script标签注入了脚本，我认为该页面可能会注意到脚本注入，甚至可以查看其代码？

沙盒模型在这种情况发生过程中是否发挥任何作用，并使它变得“更安全”而不被看到？例如，如果您使用@grant unsafeWindow来隔离js上下文，那么也许网页上的js甚至看不到任何用户脚本加载事件，从而使@grant unsafeWindow从根本上更加安全，除非您修改DOM或unsafeWindow。

我还假设没有泄漏特殊功能，对象，属性等（例如GM_info到网页，这会背叛tampermonkey吗？）。不在@grant none模式或@grant unsafeWindow模式下（前提是您没有向页面泄漏任何内容）

这让我感到unsafeWindow实际上是更安全的，因为只要您不修改任何内容（尤其是不要公开特权{ {1}}用于unsafeWindow）。例如，如果您在GM_*模式下使用了eventListener，则可能会检测到它，但是如果在@grant none模式下使用了eventListener，则可能会由于检测不到而被检测到。隔离？此外，如果某个页面有可能检测到用户脚本加载（我不知道这是否可能实现），那么它将不知道js上下文是否隔离

在简短的摘要中，如果您不背叛页面，那么页面是否可以检测到用户脚本或tampermonkey的存在？

我在上述任何方面的上述想法在任何领域都正确吗？如果是，那么它实际上是如何工作的？

更新

一些需要澄清的信息：

用户脚本仅从页面被动地读取信息（可能使用MutationObserver）。它不会以任何方式改变任何内容，不使用任何js库（既不在用户脚本中也不从网页中使用），没有ajax调用，没有脚本节点，绝对没有单击等。脚本可以从JS vars中读取一些信息页面（假设那些var和函数没有被诱杀），以及使用WebSocket（内部服务）。也使用IIFE。因此，主要的问题是，是否可以检测到篡改猴本身（如果运行页面脚本）？

在此答案中：https://stackoverflow.com/a/8548311 我可以排除1、4、5、6和7；大概也是2和3，但我不知道坦佩罗尼本身是否会影响其中的任何一个

Answer 1

如答案https://stackoverflow.com/a/8548311所述，如果您执行类似的操作绝对是可检测的。但是，根据您想对tampermonkey脚本执行的操作，这将更加容易或更难以检测，在某些情况下不可能。

根据您的询问，您似乎想做的只是从页面中调用IIFE，然后就停在那里，“假设它只是读取信息”。

捕获起来真的很棘手，通常为此，页面必须比较分析器和执行时间等其他用户与您的比较，或其他一些时髦的事情，并且没有真正简单的方法来找出是否用户在页面中执行了没有副作用的额外JS（只要您使用IIFE）。我并不是说它是100％无法检测到的，但是我们说它确实非常棘手。

如果您要修改DOM，对外部或内部服务进行API调用，用户的虚假举动或其他此类情况，您将被检测到。因此，这取决于您要对页面执行的操作，但是可以“很容易地”发现您。

在简短的摘要中，如果您不背叛页面，那么页面可以检测到您的用户脚本或tampermonkey的存在吗？

是的，在您在页面中留下痕迹的情况下（如上定义），页面可以检测到这些错误。请记住，这只会发生，因为页面有理由要知道是否正在发生这种情况。还要记住，没有页面会仅仅出于这种目的而实现这样的事情，所以不要指望普通页面会抱怨这一点。

Answer 2

浏览器和Greasemonkey / Tampermonkey / Violentmonkey（大部分）已经改进了它们的注射，作用域和沙盒处理方式。不会使用普通的<script>标签注入用户脚本（尽管您的脚本可能需要在某些情况下创建此类标签）。

事实上，如今there's almost no need to use an IIFE。

但是，除了previously linked question中的检测方法：

在@grant none模式下，如果您@require将自身复制到window范围的库，则页面可以看到它。大多数库都不会这样做，但是可以做到的就是 jQuery 。
Tampermonkey actually provides the installed script version到在高级设置中列入白名单的网站。这主要用于greasyfork.org之类的脚本主机。
我不知道页面是否可以检测到用户脚本正在使用的WebSocket。我对此表示怀疑。

底线是用于“只读”用户脚本，它不是require模式下的@grant none全局库，页面无法检测到它。< / strong>
（除非页面是greasyfork.org等，并且您将Allow communication with cooperate pages设置为默认值。）

如果您发现页面可以检测到“被动”脚本的漏洞，请通知我们，并有可能被堵塞。

Answer 3

亚马逊实现了等待 3 或 4 秒然后检索所有控制台信息的功能。

是这个样子

{
    "logs": [{
        "level": "error",
        "message": "Cannot set property 'checked' of null",
        "error": {
            "errorMessage": "Cannot set property 'checked' of null",
            "errorName": "TypeError",
            "errorStackTrace": "TypeError: Cannot set property 'checked' of null\n    at storageUpdate (chrome-extension://dhdgffkkebhmkfjojejmpbldmpobfkfo/userscript.html?name=myUserscript).user.js&id=ea4d27bb-1f9a-44e5-847c-2f61122b4d75:14467:86)\n    at Window.configModal (chrome-extension://dhdgffkkebhmkfjojejmpbldmpobfkfo/userscript.html?name=myUserscript).user.js&id=ea4d27bb-1f9a-44e5-847c-2f61122b4d75:14488:29)\n    at <anonymous>:3:100\n    at E.z.<computed> (eval at exec_fn (:1:157), <anonymous>:43:442)"
        },
        "context": {
            "logTime": 1610058101393
        }
    }]
}

这是新的，无论他们是否针对我，他们都可以清楚地看到 tampermonkey 正在发挥作用：

chrome-extension://dhdgffkkebhmkfjojejmpbldmpobfkfo/

网页可以检测到篡改用户脚本吗？

第一

第二

更新

3 个答案: