The Silverlight application interface communicated with a SOAP based web service; however, the web service responses weren’t ordinary XML. Instead, they contained a Base 64 encoded value. After digging into the application, we discovered that the web services zipped and then Base 64 encoded XML response data.
Initially, I wrote a python script to decode and unzip the data; however, it was time consuming to copy, paste, and unzip each response over and over again. My solution was to use the new API to add an Editor Tab to Burp. This editor tab automatically detects whether the HTTP response needed to be processed and then unzipped the value right in the proxy tool. The plugin source code and several screenshots are available below. The code may not be the most elegant solution, but it met my needs for being fast to develop and functional.
As I wrote the plugin, I noticed that Burp provides a useful stack trace if an exception occurs while loading the plugin; however, once the plugin is fully loaded, stack traces only show obfuscated class names for Burp. You can work around this challenge by mocking up any data needed, writing all code that doesn’t rely on the Burp API separately, and then run it with the Jython interpreter. When integrating it as a plugin, my approach was to use a lot of println statements. I had a general idea of how to use the framework, but I still needed to work out the details.
HTTP SOAP Request:
Base 64 Encoded SOAP Response:
Base 64 Decoded, Unzipped XML Content:
The plugin code is available as a gist at:
0 comments:
Post a Comment