How does javascript (or a browser extension) detect the use of restricted functions?

Question

I am developing a script extension similar to Greasemonkey or Chrome content - script. This extension will allow script writers to do very dangerous things, such as accessing local files.

If I ever release this extension to the public, I would like it to be able to alert novice users if the script uses a "dangerous" function. I would like this warning to be as difficult to get around as possible.

For example, an extension might look for a protected GM_openSQL_Connection string and warn the user - maybe, like this:

Suppose a base webpage can never access GM_openSQL_Connection thanks to sandbox mechanisms. Similarly, no <script> node can.

But the script writer could still get around a simple search from above, with something like:

 eval (decodeURI ("GM_op%65nSQL_Connection (...);") ) 

So the question is: what are the ways in which an evil scripter can trick a check on the limited use of functions , and how can I prevent such mischief?

---

Note: false warnings may be in order. For example, if the author of the script uses the text "GM_openSQL_Connection" in static statics otherwise, then he just has to put up with a (false) warning.

Answer 1

How can an evil scripter fool a test for the limited us [age] function?

There are thousands of combinations, for example with eval() , new Function() , combinations of String.fromCharCode() and decodeURI() (as in your example).

How can I prevent such mischief?

Could you overload / shade specific bad functions / objects / variables?

 GM_openSQL_Connection = function() { warnUser(); }; 

To set a flag if the extension is trying to access a forbidden function or variable, simply set var isDangerous = false , which is set to true if the forbidden function is called or get / set to access the forbidden property / changed.

If isDangerous is true , you can mark this extension as potentially having dangerous call / access features / properties.

Answer 2

Trying to scan a script to determine if it is using any of these interfaces is the wrong approach. It is too easy to avoid obfuscation, as you seem to discover. This is fundamentally unsafe: there is no way to make it work.

Here is the best approach. Require script -writer to include a manifest that declares which special APIs it needs to receive. Then run the script in a secure Javascript sandbox that provides only the allowed APIs and APIs that it requested, but nothing more. If the script does not request GM_openSQL_Connection in its manifest, do not open this API for the script.

Since Javascript is a dynamic language that allows you to render monkeys harmless and have unlimited access to the global object, some creation of a reliable sandbox is required that restricts access to the API that the script can access. Therefore, I recommend that you use an existing sandbox solution. One approach is to run the user script in the sandbox and provide an isolated code library full of stubs for sensitive APIs, where stubs simply use postMessage to send an RPC request to your extension code. This avoids links that cross the sandbox border, which is good (depending on the technology of the sandbox) these types of links usually have significant potential for security vulnerabilities.

You can then manage user alerts based on the contents of the manifest. Important: think about it from a user's perspective. Will regular users know the meaning of the warnings? Will they be able to make smart decisions? Will users be in a better position to make the right decisions than you? Will users be overwhelmed by constant alerts and just start to ignore them and click ok (cry-wolf effect)?

For information on technology for the Javascript sandbox, please read the following IT security question: How to scan Javascript for malicious code? . In the future, you may receive answers on the IT security site on this subject.