Blog | G5 Cyber Security

SQL Injection via Tokens

G5 Cyber Security

TL;DR

Yes, tokens can be vulnerable to SQL injection if they are not handled correctly. This usually happens when the token’s value is directly inserted into a SQL query without proper sanitisation or parameterisation. The solution involves using prepared statements and avoiding dynamic SQL construction.

Understanding the Risk

Tokens are often used for authentication, authorization, or to store user-specific data. If a token contains information that’s later used in a database query, it can become an attack vector if not secured properly. An attacker could manipulate the token value to inject malicious SQL code.

Step-by-Step Solution

  1. Identify Token Usage: First, find all places in your application where tokens are used within SQL queries. This includes:
    • Authentication/Authorization checks
    • Retrieving user data based on token content
    • Updating records using information from the token
  2. Avoid Dynamic SQL: Never build SQL queries by concatenating strings, especially with token values. This is the most common source of SQL injection vulnerabilities.

    Bad Example (PHP):

    $token = $_GET['token'];
$query = "SELECT * FROM users WHERE token = '$token'"; // Vulnerable!
  3. Use Prepared Statements: Prepared statements separate the SQL code from the data, preventing injection. Most database libraries support them.

    Good Example (PHP with PDO):

    $token = $_GET['token'];
$stmt = $pdo->prepare("SELECT * FROM users WHERE token = :token");
$stmt->bindParam(':token', $token);
$stmt->execute();
  4. Parameterisation: Ensure all token values are passed as parameters to the prepared statement. This tells the database to treat the value as data, not as part of the SQL command.

    The example above uses bindParam() for parameterisation.

  5. Input Validation (Defense in Depth): While prepared statements are your primary defence, validate token format and content before using them. This can help catch obvious malicious attempts.
    • Check the length of the token.
    • Verify that the token contains only allowed characters (e.g., alphanumeric).
  6. Escaping (Not a Replacement for Prepared Statements): If you absolutely must use dynamic SQL (which is strongly discouraged), use your database library’s escaping function to sanitise the token value before inserting it into the query.

    Warning: Escaping is error-prone and should only be used as a last resort. It’s far better to use prepared statements.

  7. Least Privilege Principle: Ensure that the database user your application uses has only the necessary permissions to perform its tasks. This limits the damage an attacker can do even if they manage to inject SQL code.
  8. Regular Security Audits: Conduct regular security audits and penetration testing to identify potential vulnerabilities, including those related to token handling.

Example Scenario

Imagine a reset password feature where a token is sent in the URL. If this token isn’t properly validated and used with prepared statements, an attacker could modify the token to gain access to other users’ accounts.

Key Takeaways

Exit mobile version