3

I'm editing a webpage made using Apache Wicket. And we want to add some CSRF protection to the website. Wanting it to be stateless we want to use a double submit pattern.

For forms we will probably end up using a hidden field that will contain the csrf token.

But we also need to add this to some GET request made using an AjaxFallbackLink which also changes some data (I know it shouldn't do it, but I can't change it currently). For this we are considering putting the CSRF token in a custom header that is sent with the request, but I haven't seen any way to hook into the javascript method that wicket uses (the wicketAjaxGet seems to only take a precondition function and a channel function). Are there any suggestion on how I could do this?

Or would adding the token to the url be a good option? What would the problems be in this case, compared to setting it in the header, if we're using https transmission.

Or any other ideas about how we could add CSRF protection to these Ajax GET requests?

redspider
  • 401
  • 1
  • 6
  • 21

2 Answers2

3

You can use the 6.x (and 7.x) CsrfPreventionRequestCycleListener that is packaged with Wicket

You install it in your application's init-method:

@Override protected void init() { // ... getRequestCycleListeners().add(new CsrfPreventionRequestCycleListener()); // ... } This will then check for Origin headers in all requests, including AJAX. You'll need to configure the listener with how you want it to act, which origins you want to allow, etc.

Martijn Dashorst
  • 3,652
  • 17
  • 26
  • only from 6.20+ although you you extract it from 6.20 and use it in previous versions of 6.X – tomerz Sep 29 '16 at 13:21
  • But you shouldn't do that, rather upgrade to 6.24 or 6.25 when that's available. There are lots of security issues solved in later releases. – Martijn Dashorst Sep 30 '16 at 15:12
  • @Martjin you're right....but sometimes it is not that easy to upgrade. Do you also have exp with connecting it to spring security 4? – tomerz Oct 05 '16 at 12:31
2

If you use Ajax components then the Page will be stateful.

If you are OK to have http session then the easiest way is to use CryptoMapper (note: it has many improvements in Wicket 6.x!).

If you want the page to be stateless then you have to use you own custom token - either as request header or parameter. Check wicketstuff-stateless for stateless Ajax components and behaviors.

martin-g
  • 17,243
  • 2
  • 23
  • 35
  • How would the CryptoMapper help against CSRF attacks? From what I saw wicket only adds to the url a session id (an integer that grows by 1 for each page requested) and I'm guessing it would just encrypt this url. Wouldn't an attacker be able to "guess" this session id and encrypt it himself for the attack to work? – redspider Apr 27 '15 at 07:21
  • CryptoMapper could encrypt the whole url, not just the request parameters in the query string. The secret key for the encryption is per user (i.e. per http session) so the attacker could not guess it. Make sure you use Wicket 1.5.13 because of CVE-2014-7808. – martin-g Apr 27 '15 at 07:41