BurpSuite is one of those must-have tools when dealing with web application or API security assessments.

Usually, when proxying applications through Burp, a fair amount of noise (advertising and user-tracking 3rd party services, CORS preflight checks, etc.) is also captured and displayed along with the request-response pairs we are actually interested in. While most of them can be cleaned out using a combination of the scope and proxy filtering options, that doesn’t always work well depending on the scenario. Additionally, there is no built-in functionality to automate highlighting based on user-defined criteria.

The Highlighter plugin is a rule-based engine that can assign a color (Highlight) and/or a Comment to requests and responses in the Proxy tab, according to user-defined values.

It looks like this:

Each rule specifies the color of the requests matching the parameters: search term, type and target. The engine will try to match each incoming request/response against every active rule in real time. Alternatively, the user can click “Scan history” to highlight or comment rules that are already present in the proxy history. As exposed by the Extender API, the following fields can be used to match against:

  • Request
    • Method
    • URL
    • Header
    • Body
    • Any
  • Response
    • Cookies
    • Header
    • Body
    • Mime
    • Status code
    • Any
  • Both
    • Header
    • Body
    • Any

If the match result is true, the selected action will be performed on the proxy entry, highlighting it with the specified color, adding a comment using the defined Rule Name or both.

Use cases

Status code

A simple use case like adding colors depending on the status code is demonstrated below:

Rules can be as simple or as complicated as we want; by checking the “Regex” checkbox and setting the search term to 404|301, requests returning Not Found or Moved Permanently responses will be highlighted in red. Or maybe we want every request which doesn’t return an HTTP 200 to be red, so we just check the “Negative search” option and set the search term to 200. The possibilities are endless!

Differentiating user sessions

We often need to test APIs or web applications using different users, and making requests for a specific session (or for both!) stand out can help when hunting for authorization flaws, unauthenticated endpoints, etc. We can set rules to match against “Header” for the session identifier (Cookie:, Authorization:, etc.), highlighting each session in a different color and making it easier to visually identify them. This also has an interesting “side effect”, because requests not containing those identifiers (e.g. unauthenticated requests) won’t be the same color as those containing them, which helps to spot authentication inconsistencies.

Too many OPTIONS?

If our target makes cross-origin HTTP requests, an OPTIONS request is issued as part of the CORS preflight check, which can be distracting when dealing with multiple API calls to a different origin than the static resources that comprise the application:

By default, Burp does not provide an easy way to filter them out, so we can just add a comment on every non-OPTIONS request with the following rule (note the “Negative search” flag!):

Then, on the Proxy tab, check “Show only commented items” in the “Filter by annotation section”:

And there it is, we’ve hidden all OPTIONS requests:

Testing SOAP services

When testing SOAP services, we sometimes have to deal with a single endpoint accepting multiple actions. Because the Action is specified within the SOAPAction HTTP header, by default the proxy tab only shows requests to that single endpoint, making it hard to tell between requests:

Instead of clicking on every request to check the SOAPAction header, after adding a few rules the action name will be shown in the “Comment” row of the proxy tab.

Identifying sensitive information leaks

It is common for modern web or mobile applications to contain some kind of user-tracking functionality, for marketing, analytics or other purposes. Failing to properly implement (or configure if using a third-party service) exclusions or masking for sensitive data can end up leaking personally identifiable information or sensitive data out of the application domain. If we add a simple rule to match on the test strings that are supposed to be sensitive (passwords, credit card numbers, etc) we can easily notice extraneous requests containing sensitive information.

Final thoughts and caveats

Automatically adding colors and comments to Burp’s proxy tab elements can be of great aid in assessing the security of API services or web applications. However, there are some implicit limitations to the Burp Extender API usage:

  • State persistence across projects
    • Burp Extender API does not expose per-project state load/store methods
    • Some sketchy hacks can be done to work around this issue, none of them I liked
    • Basic save/restore functionality using serialization has been implemented as a proof of concept, however, re-implementing it using JSON objects instead is a work in progress.
  • Rule order matters: because the rules are processed sequentially, last-added rules take precedence over the rest. This can be leveraged to implement complex patterns where lesser priority rules are added first and subsequent rules matching the same request will “overwrite” the request color/comments. Allowing the user to modify the rule processing order is a feature in progress for the next releases.

Source code and jar releases are available at https://github.com/ivision-research/burp-highlighter/.