Closed Bug 477380 Opened 11 years ago Closed 10 years ago
Disallow using eval() and set
Timeout(String) in chrome
(In reply to comment #0) > It is similar with setTimeout() where first parameter is a string Same thing with setInterval().
Sure, setInterval() is the same - only that I didn't see it used with dynamically generated strings anywhere.
This is one of those times I wish we had taint checking... I really do think that eval() with system principal is a bad idea, since we have native JSON support. Not sure about setTimeout.
11 years ago
(In reply to comment #3) > This is one of those times I wish we had taint checking... Only to have people "validate" with /.*/ because "then it works" :-( (In reply to comment #3) > I really do think that eval() with system principal is a bad idea, since we > have native JSON support. Not sure about setTimeout. Yes, I only found one extension that introduced a vulnerability via setTimeout() (bug 476816). However, I am afraid that if eval() is forbidden setTimeout() will be used as an obvious "workaround".
What would remain to mirror |uneval| and |.toSource()|? What about faking namespaces through |eval("code", object)| to prevent variable leaks in XBL components? And what would prevent authors from replacing |eval("code")| with |new Function("code")()| (except for no longer being able to dynamically create variables and constants and maybe having to insert a |return| at the correct place)? For further objections see the comments at the URL.
Looks like bug 515443 is implementing the ability to selectively block all of this. Maybe once that is done it can be turned on for all extensions?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 528950
You need to log in before you can comment on or make changes to this bug.