Hi,
On 08/09/2013 02:59 PM, Jim Blandy wrote:
The taint analysis applies to strings only, and has four parts:
* It identifies certain *sources* of strings as "tainted":
document.URL, input fields, and so on.
* The JavaScript engine propagates taint information on strings.
Taking a substring of a tainted string, or concatenating a tainted
string, yields a tainted string. Regexp operations, charAt, and so
on all propagate taint information. And so on.
* It identifies certain *sinks* as vulnerable: eval, 'src' attributes
on script elements, and so on.
* Finally, the tool's user interface logs the appearance of tainted
strings at vulnerable sinks. The taint metadata actually records the
provenance of each region of a tainted string, so the tool can
explain exactly why the final string is tainted, which is really
helpful in constructing XSS attacks.
[…]
I looked at the code in the github repo at
https://github.com/alagenchev/spider_monkey. It seems to me that the
following issues need to be addressed:
* The way the taint metadata is stored needs to change. A linked list
isn't appropriate for operating at scale.
I don't think we should use tainting. The extra bit on the length is
currently reserve to optimize strings which would be represented as an int.
The goal of the tainting is to re-construct the inverted data-flow graph,
i-e finding the origin of a string which flow into a function. And the
data-flow graph is basically what is monitored when we register that we can
see a new values flowing inside a store at a specific code location.
I think that if we want to capture this kind of information, we should at
least make it in such a way that we can also use it to improve our
performance. If we are able to isolate the data-flow, we could optimize our
data representation based on guarded invariants of the data-flow (dynamic
deforestation?), and with the support of a moving GC, we could
optimize/deoptimize the value representation on GCs. [to be seen as a JIT
compiler for the data flow instead of only having JIT compilers for the
control flow]
* The patch adds functions on 'String', and an accessor on
'String.prototype'. We can't really add methods directly to String,
for the sake of web compatibility. Rather, we should handle taint
the way we handle Debugger.
I agree, we should make this visible from developers tools, but not directly
added to the String interface.
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
