Issue 121: Vulnerability at chess.com, GraphQL security playground and checklist 📝

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 hikaru:

GET /v1/users?loginToken=98a161...&username=hikaru&signed=iOS3.9.7-7b9f... 
HTTP/1.1
Host: api. chess. com

Returned this kind of response:

{
  "status": "success",
  "data": {
    "email": "REDACTED",
    "premium_status": 3,
    "id": 15448422,
    "uuid": "REDACTED",
    "country_id": 2,
    "avatar_url": "REDACTED",
    "last_login_date": REDACTED,
    "session_id": "REDACTED",
    "location": "Sunrise, Florida",
    "username": "Hikaru",
    "points": 52,
    "chess_title": "GM",
    "first_name": "Hikaru Nakamura",
    "last_name": null,
    "country_name": "United States",
    "member_since": REDACTED,
    "about": "",
    "is_blocked": false,
    "is_tracked": false,
    "are_friends": false,
    "friend_request_exists": true,
    "is_able_to_change_username": null,
    "flair_code": "diamond_traditional",
    "show_ads": true,
    "is_fair_play_agreed": true
  }
}

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.

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
• Injection
  • Stored Cross-Site Scripting
  • Log spoofing / Log Injection
  • HTML Injection
• Authorization Bypass
  • GraphQL Interface Protection Bypass
  • GraphQL Query Deny List Bypass
• Miscellaneous
  • GraphQL Query Weak Password Protection
  • Arbitrary File Write / Path Traversal

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

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:

1. Understand the full scope of secure API consumption
2. Validate the data
3. Choose your web services API: SOAP vs. REST
4. Record APIs in an API registry
5. Assess your API risks
6. Be diligent about API documentation
7. Lock down access to APIs
8. Specify authentication and access
9. Stash your API keys
10. Add AI to API monitoring and threat detection

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!