Potential XSS-Vulnerability due to the way Wicket renders JavaScript in CDATA blocks?

["spam2008@meeque.de" <sp...@meeque.de>]

Hello List,


I must admit, I don't follow here too closely. But I've searched the
archive and Wicket's Jira, and have not found much discussion regarding
this Issue. So let me elaborate...


A partner pointed me to a XSS vulnerability in one of our websites built
with Wicket. The respective page uses a lot of custom JS code, and some
of it interacts with the backend, too. We use
AbstractDefaultAjaxBehavior.getCallbackUrl() to build the respective
URLs. This apparently includes URL-parameters that were used to access
the original page, no matter if these parameters are needed by the
Wicket application or not. Hence an attacker can manipulate theses URLs,
and render them into the page. 

In Wicket 1.5. that caused injection trouble when such a tampered URL
contains the closing of an XML CDATA block, i.e. the characters ]]>.
We're currently migrating the website to Wicket 6 (great work on the JS
integration there btw.) where this kind of injection does not work.
Apparently, the URLs that are returned by
AbstractDefaultAjaxBehavior.getCallbackUrl() are already sanitized. So
no more problem for us here. 


However, that all started me thinking. And in the end I could construct
a similar XSS vulnerability, even with Wicket 6.0. Here's an example,
using an IHeaderResponse:

response.render( new OnDomReadyHeaderItem( "var foo = 'Injecting CDATA
section end-tag ... ]]> </script><h1>... in order to break out of script
block</h1>'" ) );

Of course, the above is just a demo, using a static string. However, it
might aswell contain dynamic data constructed from user input. Point
being, it is a string of perfectly legitimate JavaScript code. So
JS-escaping wouldn't help much. Still it introduces a serious XSS
vulnerability IMHO.

Btw, the documentation of OnDomReadyHeaderItem merely speaks of
JavaScript -- it does not mention anything about encoding it. So as a
caller I assumed, OnDomReadyHeaderItem (or more generally Wicket) would
take care of proper escaping. 

Also, I don't think OnDomReadyHeaderItem is the only way to reproduce
this. I suspect such injection is possible almost anywhere Wicket
renders JavaScript. In particular, Wicket code ads its own
<![CDATA[ ... ]]> markers around JS code-blocks in HTML. So shouldn't it
also make sure, that these code-blocks don't contain the charactes ]]>
themselves? And somehow escape them, if needed?


Sorry, if all of that has already been discussed. I noticed a long time
ago that Wicket uses CDATA blocks for JS code. And I always assumed
Wicket would take appropriate measures to prevent code from breaking out
of these blocks. So I'm a little worried about my discovery. 


Regards,
Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org