Almost exactly one year ago SourceMapper v1.2 was released. Today we announce the release of SourceMapper v1.3!
This version sees some bug fixes and some functionality improvements. Specifically SourceMapper now:
- Raises alerts within Burp Suite when it finds configurations that need investigating and may be minor issues.
- Can identify embedded Source Maps as well as linked Source Maps.
- Has improved basic sanity and syntax checking for found Source Maps to help reduce false positives
The main improvement of this update means that the plugin doesn’t just inject Source Map headers and optionally inject local content for the browser to use. Now it also can be used to raise your awareness of any present map files.
Please see the GitHub repo here!
I recently needed to test which Content Types a web application was able to accept in a few different forms. This isn’t a particularly difficult task but I realised that there is no single list of content types in a nice easy-to-use fashion. So I made it…
You can download that list here.
This is a sample of what it looks like:
application/1d-interleaved-parityfec
application/3gpdash-qoe-report+xml
application/3gppHal+json
application/3gppHalForms+json
application/3gpp-ims+xml
application/A2L
application/ace+cbor
application/ace+json
application/activemessage
application/activity+json
As you can see, it is just a line delimited list of mime types.
I discovered that essentially it is possible to make up a mime type if you are a developer. This means that my list is guaranteed to be incomplete. At the time of writing, this list had a little over 2000 Content Types / Mime Types in it. If you notice any missing, please get in touch!
TL;DR; New BurpSuite plugin called “Look Over There” that tells Burp where to look when scanning API end points that otherwise would be like shouting into a void.
I fondly remember the good old days when restful web apps meant you could walk through the web application, check it for sanity and then use the Active Scanning techniques within Burp Suite to get a significant amount of coverage completed without much effort.
On far too many recent web application penetration tests I have found myself frustrated that Burp doesn’t understand the application’s JavaScript API calls and what they mean or where it should look for results. These are the days of the Single Page Application (SPA) and JavaScript driven API calls and the frustration grew to the point where I wrote an extension to help.
Look Over There is expected to be available in the BApp store any moment now and you can also find the source code here:
https://github.com/yg-ht/Burp-LookOverThere
The extension checks for a number of scoping requirements and if they all match it will inject a Location header and a 302 HTTP status code. This means that Burp will interpret redirection and make the necessary additional requests. If configured correctly it will request the resource in which reflected content can be found and analyse it as it ordinarily would, for example in an old-skool restful web application.
To use the extension you first need to configure it, and then you need to send the relevant request to the Scanner or to Intruder for more targeted Scanning. Configuration is straight forward, at minimum you need to enable the plugin, specify the trigger URL and specify the target URL. There are also other relevant qualities about the request that can further specify the type of transaction in order to be as precise as possible. It is important to configure it correctly to make sure the extension only operates when you want it to prevent the extension from accidentally trampling on any other possible results.
- The trigger URL is the URL that is being scanned. It triggers the extension to take action and without this, nothing happens and the tool won’t know it is supposed to do something.
- The target URL is where you want Burp to look. This should be the URL that would return the reflected content. The contents here can be in any format, for example, a full HTML page, or just a JSON blob.
