W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: XSS mitigation in browsers

From: <sird@rckc.at>
Date: Thu, 20 Jan 2011 18:06:02 -0600
Message-ID: <AANLkTikuV8nP7PM1Mi=KD7riJ-aVNg95vkMKNTg+7kB+@mail.gmail.com>
To: gaz Heyes <gazheyes@gmail.com>
Cc: Michal Zalewski <lcamtuf@coredump.cx>, Sid Stamm <sid@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>, Adam Barth <w3c@adambarth.com>, public-web-security@w3.org, Lucas Adamski <ladamski@mozilla.com>
> Am I correct on this?
Correct in the JSON thing, the E4X thing, as Gareth mention, got fixed.

XBL is not fixed though.. lets see if I find the poc..

There is a native sandbox now.. iframe@sandbox can be used to sandbox
scripts, just throw some:


on an iframe and put it in a iframe@sandbox="allow-scripts", and you
got a sandbox API :P

-- Eduardo

On Thu, Jan 20, 2011 at 5:38 PM, gaz Heyes <gazheyes@gmail.com> wrote:
> On 20 January 2011 23:23, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>> (This is also the beef I have with selective XSS filters: I don't
>> think we can, with any degree of confidence, say that selectively
>> nuking legit scripts on a page will not introduce XSS vulnerabilities,
>> destroy user data, etc)
> This would be a good argument for a native sandbox in every browser, if we
> can detect an attack (certainly possible) then we can react to it by placing
> the browser in a sandbox rather than blocking script/replacing output. The
> browser is in the best position to control the content as it's rendering it.
> If we know a pattern matches and we know where it occurs then the output can
> be sandboxed where the injection occurs. We need a way to sandbox HTML and
> JavaScript, web workers would be a nice way to execute JavaScript safely if
> they didn't send cookies with requests to import scripts and allowed
> deletion of native properties.
Received on Friday, 21 January 2011 00:06:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC