- From: <sird@rckc.at>
- Date: Thu, 20 Jan 2011 18:06:02 -0600
- 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>
@Michal
> 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..
@Gareth
There is a native sandbox now.. iframe@sandbox can be used to sandbox
scripts, just throw some:
onmessage=function(e){
e.source.postMessage(eval(e.data.code),e.origin);
}
on an iframe and put it in a iframe@sandbox="allow-scripts", and you
got a sandbox API :P
Greetz
-- 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