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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org