Re: XSS mitigation in browsers

Here's the PoC:
http://eaea.sirdarckcat.net/epicwin.xhtml

Though, only works on xhtml :(

Greetz
-- Eduardo




On Thu, Jan 20, 2011 at 6:06 PM, sird@rckc.at <sird@rckc.at> wrote:
> @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:11:51 UTC