[OWASP-ESAPI] ESAPI and CSS vulnerability/problem
Wong, Bernie
Bernie_Wong at stercomm.com
Fri Feb 13 06:30:56 EST 2009
Sent from my iPhone
On Feb 13, 2009, at 5:35, "Jeff Williams" <jeff.williams at owasp.org>
wrote:
> Hi. There’s a lot of work to report on. The input validation 2.0 tea
> m 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_Cheat_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.fro
> mCharCode (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 character
> s get messed up.
>
>
>
> Is it ridiculous to prevent a string value from starting with “expre
> ssion.*(“ or will that break something? We would have to do it rec
> ursively 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\2
> c 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 w
> e’ll have jars of all the versions easily accessible. I built this o
> ff the current SVN, and it passes the test cases, but it’s not an of
> ficial release. There may also have been some other minor API chang
> es 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
>
> 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 de
> liver 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 C
> VS. 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
>
> 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 “exprexpres
> expressionsionession”.
>
>
>
> 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
>
> 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 i
> t with you.
>
>
>
> Regards,
>
> Abe
>
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090213/c40a5a03/attachment-0001.html
More information about the OWASP-ESAPI
mailing list