Testing Apache Wicket Web Apps (1.4.x)

Apache Wicket is a Java web application framework, and its annoying to test against as it maintains a lot of state server side which makes client side manipulation difficult.

Depending on the URLCodingStrategy in use (and whether or not Encryption of the URL is in place*) you may see request containing the following parameter (or similar):

wicket:interface=:0:1:::

Each subsequent request will increase the sequence number, indicating a different version of the web page:

wicket:interface=:0:2:::
wicket:interface=:0:3:::
wicket:interface=:0:4:::

An identifier parameter with no value will be included and may be incremented for each page:

id1_hf_0=

This URL parameter tells the server which page state you are requesting. Depending on how the page has been written some will complain if requests are repeated with the wrong sequence number causing your attack to fail.

It should be possible to use the Burp Session Handling Rules to capture the new wicket:interface value as you would a CSRF token, but the macro rules didn't seem to like replacing wicket:interface and couldn't handle the identifier parameter as it changes name every time and contains no value.

I cobbled together a Burp SessionHandlingAction plugin to help overcome some of these issues and allow me to use the Repeater/Intruder/Scanner tools with valid requests, its available on Github:

https://github.com/Meatballs1/burp_wicket_handler

Its not a polished piece of work, and will probably need customization for an individual application. It also requires a Burp Macro to be recorded that will retrieve the correct wicket:interface and identifier parameters.

The steps to do this are:

1) Add Macro - The request must contain the correct wicket:interface in the response.

2) Add Session Handling - Select 'Add' > Invoke Burp Extension

3) Configure Scope

When running a tool such as Intruder or Scanner you will want to drop the number of threads down to 1. If you try and run concurrent threads you will often find that some responses will contains values from another thread. This becomes more obvious if you try to use the repeater tool whilst you have intruder running on the same page!

I hope the above is useful for someone, it has only been tested against a single installation so your mileage may vary. Instead of using a pre-recorded Macro you could extend it to perform the request using the Burp interface. This could allow more flexibility in the plugin to handle different pages automatically.

* I haven't encountered Encrypted URLs but the underlying SessionHandling actions should be able to handle this.