Published by Daniel Jensen, Principal Security Consultant, 8 November 2023
Burp Suite is a popular web application testing tool that provides various features for analysing and manipulating web traffic. Burp Suite’s features are widely used by members of the cyber security community to conduct penetration testing and security research.
Burp Suite’s built-in Match and Replace functionality effectively allows a user to specify a string or a regular expression and a value that any matches should be replaced with. This can be applied to specified areas of HTTP requests or responses, or the entire message.
Match and Replace is useful for automatically modifying HTTP traffic. You can use it to automatically insert payloads sent to the server, insert, or alter HTTP headers, and make a wide variety of other changes to HTTP traffic. However, there are some situations where the application of Match and Replace rules can be too coarse. For example, adding something like an Authorisation header via the built-in Match and Replace means that all proxied traffic will include the header, not just the host you wish to add the header for.
When testing multiple applications at once it is useful to be able to restrict things like sensitive headers to only a single application and prevent them from inadvertently being included in other in scope applications. Earlier this year I wrote the Conditional Match and Replace (CMAR) extension to deal with this issue, as well as further extending Match and Replace based functionality. The CMAR extension is available through the BApp Store:
(https://portswigger.net/bappstore/5037418cbd064e439839760567dc12d0) with the code available on GitHub (https://github.com/CyberCX-STA/cmar).
Details
The CMAR extension allows the restriction of Match and Replace functionality by specifying a condition, which can be specified on request properties such as the first line, all headers, the body, the entire request, or the request’s destination host/port. Response Match and Replace can also use the same conditions as well as allowing actions to be performed on a response based on a condition set for the associated request. This is useful when a string ordinarily occurs in many application responses, as setting a condition that matches the specific request will ensure the string is only replaced in responses to that request.
Screenshot showing CMAR graphical interface.
CMAR Conditions can be specified as literal strings, or regexes to be matched. The Match and Replace operation also allows specifying a literal string or regex and can be performed on all the same properties of a request/response as the condition check, including the target host and port. This means traffic can be selectively redirected from one host to another, based on a condition check for the request. This can be used to selectively drop requests without altering the project scope or redirecting errant requests to the appropriate host.
Other uses
Sometimes web applications are not as fast as they could be, particularly due to poor caching settings for static public resources. When proxying over a high latency connection using HTTP/1.1, time spent on redundant requests can add up and block page rendering, impeding testing.
Using CMAR, it is possible to replace and inject headers for static assets, such as those that end in .js or .css for example and set these assets to be cached by the browser.
Screenshot showing CMAR Edit Match/Replace Rule.
Preventing these requests helps speed up the application UI for the tester, which means more time available for testing and less time spent waiting for single page applications to render while they are making hundreds of requests for cacheable static files.
Limitations
PortSwigger recently announced a new API (Montoya) for Burp Suite, whereas CMAR uses the old API. As of October 2023, PortSwigger states they will “continue to support the Extender API for the time being” (https://portswigger.net/burp/documentation/desktop/extensions/creating).
There are a few functionality restrictions:
- No regex matching for the target’s port.
- CMAR cannot alter whether the connection uses TLS.
- Rules apply to all tools (Repeater, Proxy, etc)
- Rules are executed sequentially, with each rule operating on the output of the previous rule, rather than the original request. This may or may not match your expectations.
The CMAR extension provides a level of granularity over Match and Replace operations that allows testers to easily make specific changes to HTTP traffic that will be applied automatically, without being overly broad and affecting other traffic as a side effect of the rule.
CMAR allows testers to speed up testing by providing the ability to automate certain operations that would previously require toggling the built-in Match and Replace functionality, or manually altering intercepted traffic. It is now available in the BApp store. Any bugs or feature requests can be submitted via the GitHub project page.
