As the web application footprint migrates client-side, tools to thoroughly analyze and test client behavior are becoming increasingly important. Burp Suite has made some great strides in this direction with their browser-based enhancements to crawling and scanning, but when it comes time to really dig into the particulars for research, we are still very much on our own.

I wanted to have a fine-grained solution for modifying server responses that was a little more flexible than Burp Suite’s own regex-based tools. So, I created a small extension called ResponseTinker. Much like my Adhoc-Payload-Processors tool, it provides some templating of boiler-plate code and extension wiring to allow construction of anything I need from short ruby snippets. However, I probably won’t try to push this one to the App store, because in this case, a lot of the data this extension will handle comes from external sources that may not be under the tester's control. It should be safe if the code you insert is safe, but if you decide to write eval rsp[‘body’]… ????‍♂️.

So, consider that your warning to ‘aim away from face’. I implemented some crude locking around requests in the proxy listener that don't seem to cause any issues, but there may be some negative impacts on Burp Suite’s performance. I added a master on/off switch that registers and unregisters the proxy listener entirely for that reason. When the plug-in first loads the proxy, listener is in an unregistered state. This should mitigate any performance issues when the extension is loaded but not being used.

The tool provides something similar to web frameworks for implementing a servlet. Functions are written for the HTTP methods you want to handle, and two (2) objects are passed into the function, a request object representing the client request and a response object to complete or modify. In this case, the response object's properties are taken from the original server response. The servlet is selected via an associated URL/route that determines which requests should be handled. I decided to make the routing fairly restrictive. The URL must match exactly, or a regex pattern can be used where some flexibility is required, such as parameter handling. This makes it possible to narrowly respond to specific requests for resources like /WebResource.axd?d=SomeValue without accidently modifying other responses. The figure below is an example that will handle requests to https://example.com/foo?bar=, where the bar parameter has two characters in it. The plugin will replace the body with a trivial HTML document and reflect the value of bar.

The original response headers come from the upstream server and have been preserved, except for the response code or HTTP status, which is modified to 202. You might guess, based on the “Not Found” message, that the original server response was a 404.

I am currently working on replacing some JavaScript files with local modified copies that have additional debugging messages. To accomplish this, I set rsp[‘body] = File.read(‘/path/to/local/javascript.js’) in my do_GET function. I can’t use the developer console because these scripts are obfuscated and I'm trying to decipher what they are doing with mouse move and keyboard events, opening and navigating to the developer tools triggers those same mouse and keyboard events. Although not impossible, it would have been a challenge to make changes to Burp Suite’s response modification settings in the proxy tool.

ResponseTinker is also proving useful when dealing with JavaScript that is templated server-side and obfuscated. Placing break points in the debugger becomes a challenge when each time the pages is loaded, the file is different. With a little bit of clever regular expression matching and string substation, I can ensure the file gets a ‘debugger;’ statement injected where I need it.

If this sounds useful to you and you want to take it for a spin, grab the file from my git repo ResponseTinker. Make sure your jRuby environment is configured in Burp Suite and add the file on the extension tab.