检测代码是否作为Chrome扩展程序运行

Question

我正在使用一些需要作为页面运行的代码,如果它作为Chrome扩展程序运行,我希望能够做更多的事情.我正在使用的是:

<script>
if (chrome && chrome.extension) {
    // extension stuff
}
</script>

这似乎是一个很好的能力 检测.使用用户代理字符串会给我带来麻烦,因为无论上下文(网页与扩展名)如何都是一样的.

问题:是否还有其他更可靠的技术来检测Chrome扩展程序中是否有一段代码正在运行？

更新:我想知道是否有什么东西可以放入我的manifest.json文件中然后我可以回读.请注意,我正在处理的扩展不是一直运行的持久性事物,它是一个在单个窗口或浏览器选项卡中运行的内容应用程序,无需与其他窗口或选项卡或其他任何内容交互.

Answer 1

这里有如此多的复杂答案,而您可以通过检查以下内容的存在性和非空性来轻松检测您是否在Chrome扩展程序中运行chrome.runtime.id:

if (window.chrome && chrome.runtime && chrome.runtime.id) {
    // Code running in a Chrome extension (content script, background page, etc.)
}

Answer 2

我需要类似的东西。

但我不需要关心试图欺骗代码的网站。

const SCRIPT_TYPE = (() => {
    if (chrome && chrome.extension && chrome.extension.getBackgroundPage && chrome.extension.getBackgroundPage() === window) {
        return 'BACKGROUND';
    } else if (chrome && chrome.extension && chrome.extension.getBackgroundPage && chrome.extension.getBackgroundPage() !== window) {
        return 'POPUP';
    } else if (!chrome || !chrome.runtime || !chrome.runtime.onMessage) {
        return 'WEB';
    } else {
        return 'CONTENT';
    }
})();

以上应该检测4种情况

• javascript 在后台页面中运行
• javascript 在弹出页面/ iframe 中运行
• javascript 在上下文脚本中运行
• javascript 直接在网站上运行

Answer 3

从实用角度来说，这是一个很好的方法。理论上（不确定这是否相关，例如可能提供漏洞）它很容易被欺骗。我想这取决于你的背景，这有多相关。

这是一个稍微更强的想法：

if (chrome &&
    chrome.windows &&
    chrome.windows.get &&
    typeof chrome.windows.get === 'function' &&
    chrome.windows.get.toString() === 'function get() { [native code] }')

这个想法与你的相同，尽管它稍微强一些，因为据我所知，让一个对象成为一个函数并且让它的toString()值具有该值是不可能的，因为它不是有效的语法，所以即使尝试欺骗该值也不会起作用，除非你改变本机代码（这需要完全不同级别的黑客）。

不要立即记住检查这样的事情是否需要权限，但我希望这个想法很明确。

更新

我刚刚意识到，“本机代码”语法思想可以通过为现有函数添加别名来愚弄。例如

var FakeFn = Object.create;
FakeFn.toString(); // "function create() { [native code] }"

但这可以通过仔细选择我们使用的函数来解决，因为名称出现在字符串中。get可能太常见了，但是如果我们采用仅在 chrome 扩展中实现的模糊函数名称（例如captureVisibleTabof chrome.tabs.captureVisibleTab），它仍然是一个非常可移植的解决方案，因为与代码可能被其他本地用户代码欺骗的基本检查不同，它事先知道浏览器不会使用此名称实现任何本机函数，因此它在所有浏览器和所有用户代码中仍然是安全的。

更新

正如@Mathew 指出的，这个想法是愚蠢的（尽管看起来只是恶意的）。我以为我可以通过比较来解决问题，Function.prototype.toString但我发现即使这样也可以通过给原始方法起别名toString并创建一个新方法来愚弄，该新方法对于某些函数返回错误字符串，对于其他函数返回原始字符串。

总之，我的想法比原来的想法稍微强一些，因为它几乎排除了所有无意碰撞的可能性（比OP的想法略多），但肯定不能像我最初想象的那样防御恶意攻击。