With the modern web moving toward API-based single-page JavaScript applications, a lot of vulnerability classes are in theory on the decline. At the same time, the breaking up of functionality into microservice APIs has increased risk of various Authorization problems when the entire system isn’t viewed in broad context.

Unfortunately, most tooling for being able to do large-scale testing of AuthZ and related issues is at best really terrible. The security testing industries defacto tool of choice, Burp Suite, hasn’t offered a robust way to apply a set of transformations or tests to every request it sees, until various add-ons came along to provide this functionality. Each one of them had an annoyance or two, driving Justin Moore from NCC Group to scratch an itch and build AutoRepeater.

Enter AutoRepeater

The basic concept behind AutoRepeater is straight-forward, yet powerful:

  • A request seen by burp is matched against user-defined criteria such as a particular string of text
  • One or more transformations occurs on the request, and it is re-submitted automatically by AutoRepeater
  • Results of these requests are added into a table with a ton of relevant information such as response codes and response length, allowing easy analysis of interesting responses.
  • AutoRepeater uses tabs, so you can have multiple match/modify rules, each of which will execute for a single request.

A quick example

Using Github (who have a bug bounty) as an example, I quickly spotted that they were setting a cookie named dotcom_user with the name of the user account I was using (ghtest9924), so I set up an AR rule to replace any mention of that account name with a different account I have (ghtest9923) like so:

arreplace

The idea behind this is that if a single API route within the Github server-side code happens to actually trust this value and make a decision based on it, it should stand out like a sore thumb to us.

The following screen shows all the requests with their modifications made. As you can see, the cookie has automatically been modified to swap one username out for a second. The server has responded with no significant difference in this particular request, with only 2 bytes differing, meaning there’s nothing particularly interesting here.

ar main screen

In general, you’re looking to modify a given web request to something which the server should not allow (Example: removing the primary auth token) and watching for cases where it succeeds, or, you’re looking for cases where the request would be expected to fail (Example: you’ve swapped a high-privilege admin cookie out for a low-priv cookie and are browsing the admin panel) but the request sails through successfully. There are other cases, where completely unexpected things can occur.

The AutoRepeater hitlist

The following is a short list of all the typical AR tabs I’ll have open for a given web application test:

  • Find & remove the primary authentication token (generally a session cookie) to check for complete pre-auth API blunders
  • Find & replace any userID or username values with a different known value to spot AuthZ issues
  • Flip some bits/modify some bytes in a cookie value to spot an application which checks for presence of a cookie but not validity
  • Change the User-Agent header: spot parts of an application which behave different for different UAs. I usually will try a Mobile UA and a web crawler UA.
  • Change the auth token for one of a lower privilege account to spot where high-priv functioanlity can be hit by lower-privileged users
  • Changing the Content-Type header to see if an application will accept a different data format such as XML, and possibly open up related bugs such as XXE
  • Modifying HTTP Verbs for potential auth bypasses, where decisions are made based on a specific verb but others can bypass checks.