Tools for Testing of Silverlight Applications

Silverlight is a proprietary application framework created by Microsoft in 2007. Its purpose is similar to Flash by Adobe and enables the creation of Rich Internet Applications. Silverlight is available as Plug-In for different browsers (Chrome, Firefox and Internet Explorer) on the Windows and Mac OS platform [1].

In security assessments you might get in touch with an application that is completely implemented in Silverlight. This post shows you some basic tests that can be executed and some tools you can use during an assessment.

Burp Plugins

There are two Plugins available for Burp. In 2011 GDSSecurity published a plugin in Java that is able to encode and decode WCF Binary SOAP data („Content-Type: application/soap+msbin1”) [2].  This plugin is still working in Burp 1.6.03 but the setup does need two instances of Burp connected in series if you want to edit request or response data. This is due to the fact that the plugin can only be used for encoding or decoding in one Burp instance. Therefore one Burp needs to decode the request, then you can edit the request, sent it to the next Burp that will encode the request again as WCF Binary SOAP data. The plugin can be used if you execute the following command within the directory of the plugin to start Burp:

java -Xmx512m -classpath BurpExtender.jar;.<path to burp>\burpsuite_pro_v1.6.03.jar burp.StartBurp

In 2013 Nick Coblentz released a Python plugin for Burp that extended the work done by GDSSecurity so that only one instance of Burp is needed to edit the response and request of Silverlight requests [3]. Before loading the plugin, the location of the Python environment for Java (Jython) needs to be set within in Burp, therefore you need to navigate to „Extender/Options/Pyhton Environment“.  You should download Jython 2.7beta in this case as Jython 2.5 is missing a module that the plugin is using [4]. As next step you can easily load the Pyhton script in Burp via „Extender/Burp Extensions/Add“ and after the plugin has loaded the request and response with „Content-Type: application/soap+msbin1“ will be decoded.


If you are using Fiddler, there is also a third-party extension that can be used to read and modify WCF binary messages that are used by Silverlight. You can download either the extension for Fiddler 2 or Fiddler 4 or modify the source and compile it yourself, as the whole source code is also available [5].

Silverlight Spy / XAML Spy

Besides attacking the communication by using an interception proxy like Burp or Fiddler, there is a tool dedicated for testing Silverlight applications called XAML Spy [6], the successor of Silverlight Spy [7]. In conjunction with .NET Reflector or other third-party decompiler tools it is possible to decompile Silverlight applications, like an application running in the browser or an offline application that is stored on client-side.

Silverlight Spy can be downloaded as a free version [10]. XAML Spy is only available as 21-day test version for evaluation. For productive testing you have to buy a license.

Test cases

When you test a Silverlight application you should have a look at the clientaccesspolicy.xml. There is also some documentation available from Microsoft about „HTTP Communication and Security with Silverlight“ that describes some basic hardening settings [8].

During decompiling a Silverlight application you should also investigate the Isolated Storage, if there is any sensitive information stored.













Automated scanning with Burp despite Anti-CSRF token

The usage of security tokens in Web Applications is increasing rapidly, especially as more and more frameworks support this technique to prevent CSRF attacks. These anti-CSRF tokens are typically used when state-changing actions are executed, like adding a user or confirming your purchasing order.

There are web applications that use anti-CSRF tokens in the whole application. This makes the web application very robust against CSRF attacks, but makes the life of a penetration tester much harder because automated scanning becomes a nuisance.

This tutorial explains how to circumvent the anti-CSRF tokens used in requests, to execute tools like the Burp Intruder, Burp Active Scan and sqlmap.

Intruder Scan

If you want to fuzz a certain parameter in a request that is protected by anti-CSRF tokens there is an easy solution already implemented within Burp.


Click on „Add“ to define a new grep item

Just send the request you would like to analyze to the Intruder. Clear all payload positions and only select the value of the anti-CSRF token parameter and the value of the parameter you would like to be analyzed by the Intruder. Also set the attack type to Pitchfork.

In the options tab of the Intruder , the number of threads must be set to „1“, as the attack has to be executed as sequential processing. Otherwise the intruder will mix up valid and used anti-CSRF tokens.


Select anti-CSRF token in response

To circumvent an anti-CSRF token in the Intruder, it is sufficient to go to the options tab, click on „Add“ in the Grep-Extract menu and choose the value of the anti-CSRF-token in the „Define extract grep item“ menu. The start and end point will be filled out by Burp automatically after selecting the token and we can click OK.


Select payload for parameter to be tested

In the Payloads tab, we now need to select the payload type „Recursive grep“ for the identified anti-CSRF token parameter in the position tab. It is important that you also insert the token that was sent in the last valid response to be used as initial token value for the first request. The second payload can be set to whatever we want to test for.


Select payload type and insert value of valid CSRF token

If we start the Intruder now, the parameter can be tested and the initial token is used to create a valid request. The token in the responses to that is extracted by the grep-rule and inserted into the subsequent request.

In case of an error it is likely that the initial token was wrong or was already used. Then, in our browser, we again navigate to the function we would like to test, execute all of the above steps and use the token of the last response of the application in the initial payload field.

There is also an extension available for Burp Intruder to circumvent this kind of anti-CSRF token:

(1)    Burp Extension available to extend Intruder:

Active Scan

Sometimes during testing we encounter applications that already use anti-CSRF tokens during login and for every subsequent request in the application. To automatically scan a certain request in such an application, we have to:

(1)    Get the Login-Page,

(2)    Login to the application,

(3)    Navigate to the function that should be scanned and

(4)    Get the anti-CSRF token that can be used for an automated scan.


Add a new session handling rule

Steps 2, 3 and 4 always need the valid token of the last response, otherwise the requests will be invalid. To use tools that execute automatic scans like the Active Scan in Burp or sqlmap, we need to create a session handling rule and a macro to automate the steps (1) to (4) within Burp


Select „Run a macro“

We give the Session Handling rule a unique name and select „Run a macro“ in the rule actions section.

To create a new macro we click on „Add“ under „Select macro:“ in the next menu. The macro recorder will start, where we can select the appropriate requests. We must start with a request that does not need a valid token when sent to the application and select all requests until we get to the request we would like to test.


Record the „request-chain“

In our case we needed to start at the login, as all other requests needed a token when sent to the application. The first request gets the login page where no token is  required. The second request is a login request with valid user credentials, and the third request directs to the page we wanted to test. To get a valid request chain, the second and third request needs the hidden token of the response before.


Configure macro items

We can achieve this by selecting the second request and clicking on „Configure item“. There, we set the parameter that contains the token to be „Derive from prior response“. Usually this setting does not work by itself, we also need to „Add“ a custom parameter. We just select the location of the token value and use the parameter name as name for the custom parameter. This must be done for all subsequent requests.

In the „Session handling action editor“ the anti-CSRF token parameter that needs to be updated should be added explicitly.


Update parameter with anti-CSRF token

The scope of the session handling rule should be set to „scanner“. To limit the macro to certain requests we can either use „Use suite scope“ or „Use custom scope“. It is not recommended to set „include all URLs“, as every request in the scanner would then trigger the macro.


Set scope for Active Scanner

After the Session Handling rule is created we just need to enable it. As the macro navigates to the page we want to test and gets a valid token for the scanner, you can execute an active scan of this page now. For another page we would need to create a separate macro.


Every single scanner request will also trigger all the requests we defined in the macro additionally. In the case described above 100 requests of the active scanner would produce 400 requests in total, as every request requires the three requests in the macro. Therefore, the scan will take longer but will also produce more load on the server as many logins will be simulated. So, we should be careful to not overload the server during testing.


The exact same steps as for the Burp Active Scan can also be executed for sqlmap.


Set scope for sqlmap

There is just one difference: The scope of the session handling rule should be set to „proxy“. But use this setting with caution, as every request in the proxy will trigger the full macro and thus all requests in it. To limit the macro to certain requests here, it is even more important to set „Use suite scope“ or „Use custom scope“, as described above.

When the Session Handling Rule is activated we can start sqlmap. If we have a POST-request saved to a file we can use:

./ -r request.txt –proxy=

If we have a GET-request we can use:

./ –u „“ –proxy=