Hi Ehsan, That’s been the impression I’ve been getting from asking around. I think it might be a kind of rabbit hole of a test case, and I’m especially worried that it could cover 80% of known obfuscation attempts, but that wouldn’t be much good :-)
Thanks a lot for the links, I’ll check into them. Cheers, - tofumatt On 9 October 2015 at 15:40:11, Ehsan Akhgari ([email protected]) wrote: This is not possible to achieve through static analysis based on the source code level constructs. In other words, you cannot build a tool that looks at source code, analyzes the tokens appearing in it, and infer whether a property on an object has been accessed. To detect this kind of pattern, you should probably look at methods using symbolic execution. Very simplistically, symbolic execution looks at the program's input (typically from the user and/or the external world) and assumes that the input can be any valid value according to some constraints (in typed languages for example, you start by assuming that an integer input can take any valid value in the range acceptable by the type of the variable it is stored in). Then you start evaluating the program and as you make progress, you learn about the possible subranges of a value. Through following different branches in a program like this, you will find a set of constraints which can cause a program to take a specific path, and sometimes solving the system of constraints obtained like this gives you input values that can cause a program to take a specific path (an unsafe operation, for example.) I'm not really sure how much this technique can be used on JS. Based on some quick searches, I found a number of resources which you may find interesting: * http://webblaze.cs.berkeley.edu/2010/kudzu/kudzu.pdf * https://code.google.com/p/js-symbolic-executor/ (which I'm exporting to github to make sure it won't get lost right now: https://github.com/ehsan/js-symbolic-executor/) * https://github.com/SRA-SiliconValley/jalangi (the readme says it has an undocumented symbolic execution engine, not sure how useful it is since the project is now replaced with jalangi2.) That all being said, analyses based on symbolic execution even in typed languages have a lot of practical limitations and using it even for the simplest cases such as your example below in JS may very well turn into a research project that would result in nothing in practice. In my opinion, it's impractical to detect any useful properties in an add-on JS code statically based on the source code. On 2015-10-08 4:32 AM, tofumatt wrote: > Hi there static analysis folks! > > I’m tofumatt, I'm working with Stuart Colville on the new add-ons validator, > written in JS. > > One of the things we’d like to improve in this validator is the ability to > detect rule bypassing via code obfuscation. For example, mozIndexedDB is a > deprecated identifier and that is easy to find with a custom ESLint rule. But > if someone types: > > > var badDB = ‘m’; > badDB += ‘oz’ > badDB = badDB + ‘IndexedDB’; > var myDeprecatedDB = window[badDB]; > > > The existing validator and our scans for an identifier with AST (using > ESLint/ESPrima) don’t catch it. > > Are there any tools (especially JS ones!) that can be used to at least detect > this kind of obfuscation? Without it the validator remains more an > advisory/helpful tool than something we could use to automate security > validation. > > Apologies if this is the wrong list; didn’t know exactly who to turn to for > this (I’ve also asked security and spidermonkey folks). If I should check > with someone specific, please let me know. > > Cheers, > > - tofumatt > _______________________________________________ > dev-static-analysis mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-static-analysis > _______________________________________________ dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
