[Esapi-user] JavaScript encoding

Jim Manico jim.manico at owasp.org
Wed Aug 18 14:01:29 EDT 2010


> Pretty sure if you wanted to put untrusted data into window.setInterval()
you could do it by double JavaScript encoding.

 

But why? setInternal takes a *function signature* not a normal string. This
is basically the same as doing

 

<script><%= userdata %></script>

 

And to Jeff's point, this is not REALLY injection - but remote code
execution.

 

So I say we recommend that programmers just never put untrusted data in a
large number of JS functions, (which Abe and I and reviewing now) - and
slackers seems to already discuss in good depth.

 

- Jim

 

 

From: jeremy.long at gmail.com [mailto:jeremy.long at gmail.com] 
Sent: Wednesday, August 18, 2010 6:00 AM
To: Jim Manico
Cc: gaz Heyes; ESAPI-Developers; esapi-user at lists.owasp.org; Abraham Kang
Subject: Re: Re: [Esapi-user] JavaScript encoding

 

Pretty sure if you wanted to put untrusted data into window.setInterval()
you could do it by double JavaScript encoding. The first encoding is
stripped by the setInterval() and the second encoding keeps the untrusted
data as data vs being treated like code. Something like:

<script>
window.setInterval('alert("this is safe: "<%=
ESAPI.encoder().encodeForJavaScript(ESAPI.encoder().encodeForJavaScript(");a
lert('I XSS you Beef');") %>');
</script>

Depending on how the untrusted data was actually used you may have to layer
in other encoding...

--Jeremy

On Aug 18, 2010 4:17am, Jim Manico <jim.manico at owasp.org> wrote:
> Well,
> 
> 
> Once you call eval or window.setTimeout with any untrusted data - it's
game xss over no matter how you encode. The arguments to those functions are
the same as userdata between script tags.
> 
> -Jim Manicohttp://manico.net
> 
> 
> On Aug 18, 2010, at 12:57 AM, gaz Heyes gazheyes at gmail.com> wrote:
> 
> 
> 
> What's the output look like? Then you also have to account for entities
too (depending on the context):-
> 141lert(1)')">test
> 
> 
> On 18 August 2010 07:30, Jim Manico jim.manico at owasp.org> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hello folks,
> 
>  
> 
> I've been trying to get my head wrapped around DOM based XSS
> and JavaScript encoding in a way that is easy to communicate to a mass
> audience. Abe Kang has been kind enough to talk me though these issues.
> 
>  
> 
> In my opinion, our JavaScript encoder
ESAPI.encoder().encodeForJavaScript(taint)
> needs more explanation/documentation, and the ESAPI for JS project needs
to be
> integrated in the XSS Cheatsheet more. Abe thinks there are at least 5 new
XSS
> Cheatsheet rules specific to DOM XSS - and we will be working on it over
the
> next few weeks. I love this stuff - the rabbit hole never ends. J 
> 
>  
> 
> So for starters, we edited rule #3 of the XSS Cheatsheet to
> briefly discuss illegal JavaScript contexts:
> 
>  
> 
>
http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Che
at_Sheet#RULE_.233_-_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_
HTML_JavaScript_Data_Values
> 
> 
>  
> 
> The long and short of it is - there are some JavaScript
> contexts that can NEVER handle user data - even if JavaScript encoded!
> 
>  
> 
> Try this little chunk of JSP out. Run this in Chrome, so you
> can kill the never ending popup easily.. 
> 
>  
> 
> script>
> 
> 
> window.setInterval('
> ESAPI.encoder().encodeForJavaScript("alert('I XSS you Beef');") %>');
> 
> 
> script>
> 
> 
>  
> 
> Are we on the right track? 
> 
>  
> 
> Cheers All,
> 
> Jim 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100818/f1cd4133/attachment.html 


More information about the Esapi-user mailing list