Issue 130: GitHub’s new token format, MindAPI, Kiterunner

API keys can be or look like pretty much anything. And like any other means of authentication, they are very sensitive if they leak out and fall into the wrong hands.

Designing API tokens that follow unique patterns is one of the security best practices gaining traction lately. This enables tools that can detect these API keys, for example, in code repositories or logs, and can thus prevent leaks.

In our issue 109, we covered the approach that Dynatrace took with their tokens. Now, GitHub has published a blog post on the changes to the token format on their side:

1. Unique prefix clearly separated by an underscore: All tokens now start with three letters, gh for “GitHub” and the 3rd letter to identify the kind of token:
   • ghp_ for GitHub personal access tokens
   • gho_ for OAuth access tokens
   • ghu_ for GitHub user-to-server tokens
   • ghs_ for GitHub server-to-server tokens
   • ghr_ for refresh tokens
2. Increased entropy in the random section of the token string
3. Checksum characters to separate false positive hits from actual tokens

This format allows easily to locate tokens with grep and other tools, with reliable results and not too much additional noise.

Mindmaps can be a great way to visually organize information, especially when it comes to large concepts, and API security is no different here.

David Sopas has put together a project, MindAPI, to bring “order to API hacking chaos.” The project collects best practices, tips and tricks, and tools for:

• API reconnaissance: how to discover undocumented APIs
• Vulnerability testing for each of the risks on the OWASP API Security Top 10 list

To make this big bundle of information easier to approach, Sopas has put together an interactive mindmap that shows how things go together.

And if you got interested, you can also contribute to the project.

GraphQL is still small fry in the world of APIs, but it continues to pique pentesters’ interest. Which is no wonder considering that Facebook heavily relies on GraphQL implementation, and quite a few other companies are also starting to expose GraphQL endpoints.

If you need an introduction to GraphQL penetration testing, check out this recent blog post by YesWeHack. They cover:

• Introspection
• Fuzzing (when introspection is off)
• Query flaws
• Mutation flaws
• SQL injections
• Debug information
• Batching attacks
• Tools
  • GraphQL Voyager
  • InQL

We have previously featured GraphQL pentesting and resources in our issues 125, 121, 116, 114, 96, and 82.

Speaking of API reconnaissance, Kiterunner is a new tool for it that is worth checking out.

Traditionally, API recon is done simply by using large dictionary files of possible paths and path parameters and iterating through them.

Shubham Shah decided to optimize this process. He noticed that many APIs get generated by frameworks, such as Flask, Rails, and Express, rather than designed from scratch by humans. Since frameworks are not exactly random in the way they work, he decided to build a recon model based on a large sample of API contracts.

Shah collected about 67,500 OpenAPI files available on the internet, like in APIs.guru and GitHub, and used them to pull together a model for framework-generated APIs. For more details on the research process, see his detailed blog post.

Kiterunner is an open-source tool. You can check out its repo here.

And if you want to see a demo, here’s a video on it by Katie Paxton-Fear: