[OWASP-ESAPI] ESAPI and CSS vulnerability/problem

Fri Feb 13 00:09:45 EST 2009

Hi. There's a lot of work to report on. The input validation 2.0 team is
close to finishing the design after prototyping a new strategy pattern
approach to ensure extensibility.  And there's a great case study from
Infinite Campus coming soon.

But right now I have a problem with using untrusted input in style
attributes.  The problem is IE7's stupid use of "expression" to allow
javascript.  There's no good way to use escaping to get around it.  I
discuss the problem more fully on the OWASP site.

http://www.owasp.org/index.php?title=XSS_(Cross_Site_Scripting)_Prevention_C
heat_Sheet 

Here's the test case.

        <div style="width:<%=input %>;">text</div>

What can I do to prevent "expression" from working with encodeForCSS()?  It
seems that no amount of escaping will fix this.  Actually, if you put
something in like "expression(alert(String.fromCharCode (88,88,88)))" using
CSS encoding (which uses \xx with *hex*) the browser gets all confused
because it treats the alert() part like JavaScript, which uses \xxx with
*octal*). So all the characters get messed up.

Is it ridiculous to prevent a string value from starting with
"expression.*("  or will that break something?  We would have to do it
recursively to prevent the embedded attack Abe suggests.

--Jeff

From: Abe [mailto:abek1 at sbcglobal.net] 
Sent: Thursday, February 12, 2009 3:56 AM
To: jeff.williams at owasp.org
Subject: RE: ESAPI and CSS vulnerability/problem

Hi Jeff,

Sorry I couldn't get back to you sooner

I got some bad news.  I ran the tests on IE6 and IE7 and the following is
still executable in both with the new encoding:

<div style="width: expression\28 alert\28 String\2e fromCharCode\20 \28
88\2c 88\2c 88\29 \29 \29 ;">

            Mouse over

        </div>

Here is the test case:

<% String temp3 =
ESAPI.encoder().encodeForCSS("expression(alert(String.fromCharCode
(88,88,88)))");%>

        <div style="width: <%=temp3%>;">

            Mouse over

        </div>

The code I got from you did not run however when I ran my tests again with
the new ESAPI1.5 it ran the XSS code.

It looks like the API is placing spaces after each of the encodings and this
is allowing the attack to run.

Your example that you sent me did not have spaces:

<div style="width:
expression\28alert\28String\2EfromCharCode\28\88\2C83\2C84\29\29\29;">

            Mouse over

        </div>

My guess is that the spaces are allowing the content to be executed.

When looking at the CSSCodec.java class in the encodeCharacter method it is
adding the space there.  Is the space required.

Regards,

Abe

  _____  

From: Jeff Williams [mailto:jeff.williams at owasp.org] 
Sent: Thursday, February 05, 2009 11:10 PM
To: 'Abe'
Subject: RE: ESAPI and CSS vulnerability/problem

Hi Abe,

We're in the process of setting up a Hudson/Maven build server, so we'll
have jars of all the versions easily accessible. I built this off the
current SVN, and it passes the test cases, but it's not an official release.
There may also have been some other minor API changes that you'll need to
update in your code.

Please let me know if this works for you.  If you have any problems, let me
know.

--Jeff

Jeff Williams, Chair

The OWASP Foundation <http://www.owasp.org/> 

work: 410-707-1487

main: 301-604-4882

From: Abe [mailto:abek1 at sbcglobal.net] 
Sent: Thursday, February 05, 2009 10:55 PM
To: jeff.williams at owasp.org
Subject: RE: ESAPI and CSS vulnerability/problem

Looks great.  Stopped the XSS.

You wouldn't happen to  have a jar of the latest code available.

I just didn't have the time to setup everything because I have to deliver
something tomorrow.

Regards,

Abe

  _____  

From: Jeff Williams [mailto:jeff.williams at owasp.org] 
Sent: Thursday, February 05, 2009 6:03 PM
To: 'Abe'
Subject: RE: ESAPI and CSS vulnerability/problem

Hi Abe,

I'd be interested in your experiments with the latest version from CVS.  To
be a bit safer, we changed several of the codecs to NOT use the simple
"shortcut" escaping syntax like \( and \,  - instead we always use \HH
encoding.  This results in.

<div style="width:
expression\28alert\28String\2EfromCharCode\28\88\2C83\2C84\29\29\29;">

            Mouse over

        </div>

Which doesn't execute for me in IE7.  Can you test in IE6?  Thanks!

--Jeff

Jeff Williams, Chair

The OWASP Foundation <http://www.owasp.org/> 

work: 410-707-1487

main: 301-604-4882

From: Abe [mailto:abek1 at sbcglobal.net] 
Sent: Thursday, February 05, 2009 5:09 PM
To: jeff.williams at owasp.org
Subject: RE: ESAPI and CSS vulnerability/problem

Great article.

It is definitely one of the top articles explaining the issue of XSS.

The only concern I have with it is it seems to imply that using the
encodeForCSS(.) makes request input safe (as the variable is named).

The way you suggested (removing  "expression") is a great start as long as
it is recursive (to get rid of instances like
"exprexpresexpressionsionession".

I am trying to install IE6 to test the following (which has been CSS output
escaped):

<div style="background-color: green\; background\-image\:
url\(javascript\:alert\(123\)\);">
        </div>

I thought the CSS escaping was working but I just noticed that this exploit
only works in IE6.

If you got IE6 I am trying to determine what exactly CSS encoding mitigates.

Regards,
Abe

  _____  

From: Jeff Williams [mailto:jeff.williams at owasp.org] 
Sent: Thursday, February 05, 2009 11:27 AM
To: 'Abe'
Subject: RE: ESAPI and CSS vulnerability/problem

Hi Abe,

For a complete discussion of escaping, please refer to my recent article at
OWASP.
https://www.owasp.org/index.php?title=XSS_(Cross_Site_Scripting)_Prevention_
Cheat_Sheet. This problem is mentioned in the CSS section, although it could
be clearer.

The problem is that I can't think of a way to escape/encode an 'expression'
property in IE to make it safe.  It's really an example of "injecting down".
The only thing I can think of is to disallow the expression property.  It's
not really escaping/encoding, but it seems like a good idea.

What do you think?

--Jeff

Jeff Williams, Chair

The OWASP Foundation <http://www.owasp.org/> 

work: 410-707-1487

main: 301-604-4882

From: Abe [mailto:abek1 at sbcglobal.net] 
Sent: Thursday, February 05, 2009 12:39 PM
To: jeff.williams at owasp.org
Subject: ESAPI and CSS vulnerability/problem

Hi Mr. Williams,

My name is Abraham Kang.

I am trying to advocate the use of ESAPI in my company.  While preparing a
training class I ran across a vulnerability in encodeForCSS() method.

Here is the test code I used:

<% String temp3 =
ESAPI.encoder().encodeForCSS("expression(alert(String.fromCharCode
(88,83,83)))");%>

        <div style="width: <%=temp3%>;">

            Mouse over

        </div>

Here is the output:

<div style="width: expression\(alert\(String\.fromCharCode
\(88\,83\,83\)\)\);">

            Mouse over

        </div>

With the result that and dialog box with "XSS" appears (in IE7).

I didn't want to post this to the group because I wanted to verify it with
you. 

Regards,

Abe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090213/6948b246/attachment-0001.html 