[Esapi-user] JavaScript encoding

Jim Manico jim.manico at owasp.org
Wed Aug 18 15:03:56 EDT 2010


> I hate to say the B-word, but what if you blacklist.

 

*thwap, thwap, thwap*  . but bonus points for admitting your sin up front.

 

But honestly, I think blacklist validation is a very good thing - but only
if you do it *in addition to* whitelist validation. But then you are really
talking IDS/IPS functionality. AUG-mented AppSensor rules might provide this
functionality.

 

What we really need is for developers to never put untrusted data into these
numerous JavaScript functions. 

 

I'm thinking ahead a few years when easy XSS will be eliminated (audacity of
hope) and attackers will need to resort to more difficult
flow/JavaScript/DOM based XSS.

 

- Jim

 

From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of August Detlefsen
Sent: Wednesday, August 18, 2010 11:42 AM
To: esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] JavaScript encoding

 

That is going to be a long list. If you look at jQuery (one of the most
popular libraries) for example, there must be at least a hundred functions
which can accept another function as a parameter -And that does not even
count plug-ins. 

I hate to say the B-word, but what if you blacklist ( and ) plus their
encoded equivalents? That should prevent any valid function signature from
being passed but still allow most variables, JSON, etc. 

-August 


On 8/18/10 11:01 AM, Jim Manico wrote: 

> 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  <mailto:jim.manico at owasp.org>
<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 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

 
 
_______________________________________________
Esapi-user mailing list
Esapi-user at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-user





-- 
August Detlefsen
CEO/Web Application Architect
CodeMagi, Inc. 
http://www.codemagi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100818/d32bb59b/attachment.html 


More information about the Esapi-user mailing list