Issue 109: API token best practices, Dredd, IDOR hunting tips 🔬

Although the campaigns are finally over, the US elections still feature in our newsletter. This time the dubious star of the week is the website that Trump campaign launched to collect anecdotal evidence of voting issues. Unsurprisingly, researchers found that the APIs behind the site where poorly protected and leaking voter information.

The first issue was in an API behind the site allowed bulk retrieval of voter registration data. Secondly, the API key and application ID required for the API calls could be easily found and reused. This way, attackers could programmatically crawl through the data set and scrape the personal details to build a nice asset for further attacks.

The API in question has since been removed from the page.

In addition to this, there have been allegations on SQL injections that would allow retrieving a lot more data from the underlying database, as well as allegations of the site leaking the last 4 digits of social security number (SSN) and dates of birth on top of voter names and addresses.

We covered in our issue 102 how both campaigns’ mobile apps also had API vulnerabilities.

API tokens (API keys) can be pretty much anything, so it is always good when companies are sharing their design decisions and rationale behind them. Barbara Schachner from Dynatrace has written a blog post on the new API token format that they have adopted.

All API tokens there now consist of 3 sections, separated by dots:

1. The dt0c01 prefix, to clearly separate Dynatrace tokens from others.
2. A 24-character public alphanumeric string that is both unique as well as safe to display on the UI and write to logs for troubleshooting and account identification.
3. A 64-character secret alphanumeric string that acts as the password, never to be shared or made visible anywhere.

Dynatrace have also shared a regular expression for the token detection and are working with GitHub to get the GitHub secret scanning service to automatically detect their tokens in the committed source code.

If left unchecked, API responses may leak data (see OWASP API3:2019 — Excessive data exposure) and lead to further attacks and breaches. Thus, it is important to ensure that your APIs only return the data they are supposed to return, and that new versions of the API don’t accidentally change that.

Dredd is an open-source tool that can help with that. It is a response verifier that takes examples from the OpenAPI definition of the API, invokes the API, and then compares the received responses to what is declared in the OpenAPI specification.

A handy way to keep on top of your API responses, and you can integrate it to your test suite.

(Dredd is kind of an open-source alternative to a subset of the 42Crunch Conformance Scan. The difference is that Dredd only looks at API responses while 42Crunch also ensures that the calls outside the contract – different paths, verbs, parameters, payloads, patterns, etc. – also get rejected.)

Katie Paxton-Fear has posted a new getting started video in which she covers the basics of Broken object level authorization (BOLA/IDOR), with a little bit of broken authentication, broken function level authorization, undocumented CRUD, tools, and tricks on the side. As always, worth checking out.