我正在开发一个脚本扩展,类似于Greasemonkey或Chrome的内容脚本引擎。这个扩展将允许脚本编写者做非常危险的事情,比如访问本地文件。
如果我将该扩展发布给公众,我希望它能够警告初学者,如果一个脚本将使用“危险”的功能。我希望这个警告尽可能难以绕过。
例如,该扩展可以搜索受保护的字符串GM_openSQL_Connection,并警告用户--可能像这样:
假设由于沙箱机制,基础网页永远无法访问GM_openSQL_Connection。同样,任何script节点也无法访问。
但是,脚本编写者仍然可以绕过上述简单搜索,例如:
所以问题是,恶意脚本编写者可以用哪些方法欺骗受限函数使用检查,我该如何防范这种恶作剧?
注意:虚假警告可能是可以接受的。例如,如果脚本作者在静态字符串中使用文本“GM_openSQL_Connection”,那么他只需要忍受(虚假的)警告。
如果我将该扩展发布给公众,我希望它能够警告初学者,如果一个脚本将使用“危险”的功能。我希望这个警告尽可能难以绕过。
例如,该扩展可以搜索受保护的字符串GM_openSQL_Connection,并警告用户--可能像这样:
![Bad script warning](https://istack.dev59.com/HqsI4.gif)
但是,脚本编写者仍然可以绕过上述简单搜索,例如:
eval (decodeURI ("GM_op%65nSQL_Connection (...);") )
所以问题是,恶意脚本编写者可以用哪些方法欺骗受限函数使用检查,我该如何防范这种恶作剧?
注意:虚假警告可能是可以接受的。例如,如果脚本作者在静态字符串中使用文本“GM_openSQL_Connection”,那么他只需要忍受(虚假的)警告。
var foo = window["GM_op" + "enSQL_Connection"];foo(...)
。您不能仅依靠函数名称,因为函数名称可以轻松更改。 - Wladimir Palanteval
。 - Brock Adamswindow
变量,但是可以使用this
代替。坦率地说,我认为控制“危险”API使用的唯一正确方法是首先不要公开这些API-也许应该暴露代替物,以显示警告。 - Wladimir Palant