API Security Weekly: Issue #121
This week, get the latest on API vulnerabilities and helpful hints to secure your APIs.
Join the DZone community and get the full member experience.Join For Free
This week, we take a look at the recent API vulnerability at chess.com, resources for GraphQL API security, and some API security advice from Michael Cobb at TechTarget.
Sam Curry found an API vulnerability that allowed arbitrary account takeover in chess.com, a popular online chess community and app.
Community members can exchange messages, both online and in the app. Hence, there is an API powering that feature and locating user records. Unfortunately, this API was exposing way too much information than was required for sending a message to a user.
So a call like the following, looking for a user with the username
Returned this kind of response:
The response included some personal information about the user, like the email address. Even worse, the
session_id field in the response turned out to be the security token that authenticates the user! So after a simple call to find a user, an attacker would be able to log in as that user and take over the account.
But that was not the end of it. Even worse, Curry discovered that for an admin user, he could use that token to log in to admin.chess.com, the administrative console for the entire community, and take over everything with the admin account.
This is a classic case of the OWASP API3:2019 — Excessive data exposure vulnerability. To prevent it:
- Properly define the response schemas of each API operation.
- Review the response schemas to keep the exposed data to the bare minimum necessary for the application. Avoid exposing any sensitive information should the data get into attackers’ hands.
- Finally, enforce these responses with proper validation of any outgoing data.
Resources: Damn Vulnerable GraphQL Application
Damn Vulnerable GraphQL Application (DVGA) by Dolev Farhi and Connor McKinnon is a purpose-built, highly insecure GraphQL application. You can use it as a playground to see some of the most frequent GraphQL vulnerabilities in action.
The application currently covers the following GraphQL vulnerability scenarios:
- Denial of Service
- Batch Query Attack
- Deep Recursion Query Attack
- Resource Intensive Query Attack
- Information Disclosure
- GraphQL Introspection
- GraphQL Interface
- GraphQL Field Suggestions
- Server-Side Request Forgery
- Code Execution
- OS Command Injection #1
- OS Command Injection #2
- Stored Cross-Site Scripting
- Log spoofing / Log Injection
- HTML Injection
- Authorization Bypass
- GraphQL Interface Protection Bypass
- GraphQL Query Deny List Bypass
- GraphQL Query Weak Password Protection
- Arbitrary File Write / Path Traversal
Resources: GraphQL Security Cheat Sheet
If you are on the defending side in GraphQL and want to protect your GraphQL APIs, check out this GraphQL Security Cheat Sheet from OWASP.
This page provides guidance on how to implement the following in GraphQL:
- Input validation
- DoS protection
- Access control
- Security configuration
Opinion: API Security Guidelines
TechTarget has published the top 10 API security guidelines and best practices from Michael Cobb. Arguably, to me personally, some of these look slightly contestable, but Cobb does a good job in explaining why he put each on the list. Below is the quick list. Check out the original article for more details:
- Understand the full scope of secure API consumption
- Validate the data
- Choose your web services API: SOAP vs. REST
- Record APIs in an API registry
- Assess your API risks
- Be diligent about API documentation
- Lock down access to APIs
- Specify authentication and access
- Stash your API keys
- Add AI to API monitoring and threat detection
Vote for Us
If you have not done that yet, please vote for our newsletter in the 2020 DZone Audience Awards by picking Dmitry Sotnikov (me ;)) here.
Your vote will help us spread the word and raise awareness of API security.
Huge thanks in advance!
You can subscribe to this newsletter at APIsecurity.io.
Published at DZone with permission of Dmitry Sotnikov, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.