Perl's tainting was unsound (they didn't taint the pc, so vulnerable to
implicit flows [Denning, 1976 IIRC]).
Tainting the pc leads to label creep without some static or hybrid
analysis to help untaint at control flow joins. My Netscape 3
experimental data tainting security implementation did not untaint, and
suffered fatal label creep -- this negative result cemented the
same-origin policy in browsers, which I'd been patching like a monkey
since the beginning, and which only gained sound implementation with
wrappers much later (jst, mrbkap and me in 2004-5; other browsers even
later). OCap FTW!
John Mitchell's browser-grad-student-research kids, now all growed up at
Google (Adam Barth) and CMU West / Apportable (Collin Jackson), are down
on information-flow security, due to label creep or the complex analyses
required to avoid it. I tend to agree but have a hunch it will rise again.
It turns out dherman is working with a grad student doing a taint model;
cc'ing him.
/be
Nicholas Nethercote wrote:
On Fri, Aug 9, 2013 at 2:59 PM, Jim Blandy<[email protected]> 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.
Are there any operations that are considered to untaint tainted
strings? I seem to remember that in Perl's taint mode a regexp
search-and-replace operation untaints, but I could be wrong.
Nick
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
