Role misassignment

web_auth_sessions Difficulty 1–5 30 min certifiable

Theory

Why This Matters

Role misassignment vulnerabilities have enabled some of the most consequential privilege escalations in web application security history. In 2021, a researcher discovered that a major commerce platform's partner portal accepted a role parameter in its API that could be set to admin during account creation, bypassing the manual approval workflow designed to restrict admin access. In 2022, a bug bounty report on a cloud storage provider demonstrated that modifying the account_type field in a JWT payload (signed with a weak HS256 secret crackable via hashcat) elevated a free-tier user to enterprise access, unlocking terabyte-scale storage and collaboration features. OWASP Broken Access Control (A01:2021) is the top-ranked web application risk specifically because role enforcement failures — including role misassignment at registration and role claim tampering in tokens — are pervasive and high-impact.

Core Concept

Role misassignment encompasses multiple related failure modes where a user obtains a higher-privilege role than intended, either by supplying their own role at account creation, by tampering with a role claim in a token, or by exploiting a race condition between role assignment and authorization enforcement.

The first failure mode is client-controlled role at registration: the application accepts a role or account_type field in the registration request body and assigns it without server-side validation. This is a mass assignment variant specific to the role field.

The second failure mode is JWT role claim tampering: the application encodes the user's role in the JWT payload ("role": "user") and the client modifies the payload before re-signing. This requires either a weak signing secret (crackable offline), the use of the none algorithm (where the signature is omitted and some libraries accept it), or an algorithm confusion attack (RS256 → HS256 using the public key as the HMAC secret — documented by Tim McLean in 2015 and still present in some libraries).

The third failure mode is a race condition between role check and operation: an elevated permission is granted temporarily (e.g., during an OAuth flow, a trial period activation, or an admin impersonation session), and if the attacker can trigger a privileged operation during that window — even milliseconds wide — they can execute admin actions before the permission is revoked.

The fourth failure mode is role inheritance bugs: a user placed in multiple groups may inherit the most permissive role from any group, even if they were only intended to have the least permissive role. Testing requires systematically adding a test user to every available group or role combination.

Technical Deep-Dive

-- Attack 1: Role injection at registration
POST /api/users/register HTTP/1.1
Host: victim.com
Content-Type: application/json

{"username":"attacker","email":"[email protected]","password":"P@ss1","role":"admin"}

HTTP/1.1 201 Created
{"id":502,"username":"attacker","role":"admin"}
-- Server accepted client-supplied role value

# Attack 2: JWT HS256 secret cracking
# Capture a valid JWT from the application responses
JWT="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI3NyIsInJvbGUiOiJ1c2VyIn0.SIG"

# Crack the secret offline with hashcat
echo "$JWT" > jwt.txt
hashcat -a 0 -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt
# If cracked: SECRET = "supersecret"

# Forge a new JWT with role=admin using the cracked secret
python3 - <<'PYEOF'
import jwt, json
payload = {"sub": "77", "role": "admin"}
token = jwt.encode(payload, "supersecret", algorithm="HS256")
print(token)
PYEOF

# Attack 3: JWT none-algorithm bypass
import base64, json

header  = base64.urlsafe_b64encode(
    json.dumps({"alg":"none","typ":"JWT"}).encode()
).rstrip(b"=")
payload = base64.urlsafe_b64encode(
    json.dumps({"sub":"77","role":"admin"}).encode()
).rstrip(b"=")
# Trailing dot preserves the empty-signature structure
token = f"{header.decode()}.{payload.decode()}."
print(token)
# Submit as Authorization: Bearer <token> to test none-algorithm acceptance

Security Assessment Methodology

Inspect registration and profile-update requests — Capture all POST/PUT/PATCH requests for user creation and profile modification. Look for role, account_type, is_admin, tier, plan, and permissions fields in request bodies or URL parameters.
Inject privileged role values — Add or modify role fields in registration and update requests. Submit with values such as admin, superuser, manager, staff, and enterprise.
Decode and inspect JWTs — Use jwt.io or the jwt CLI to decode every JWT the application issues. Note all payload fields, especially role, scope, permissions, and account_type.
Test the none algorithm — Modify the JWT header to {"alg":"none"}, modify the payload role to admin, and remove the signature (trailing dot must remain). Submit the modified token.
Crack weak HS256 secrets — Extract the JWT and run hashcat with -m 16500 against common wordlists. If the secret is cracked, forge a new token with an elevated role.
Test algorithm confusion (RS256 → HS256) — If the application uses RS256, obtain the server's public key (often available at /jwks.json or /.well-known/jwks.json) and attempt to sign a forged token with HS256 using the public key as the HMAC secret.
Test role inheritance — Add the test user to every available group or organizational unit and verify whether they inherit permissions from a higher-privilege group.

Defensive Countermeasure — Never accept a role or privilege field from client-supplied registration or update request bodies; derive the role server-side from a verified identity claim or an administrator-controlled assignment workflow. Use a strong JWT signing secret (minimum 256 bits of entropy for HS256, or prefer RS256/ES256 with proper key management). Explicitly reject tokens with alg: none or unexpected algorithm values. Validate the alg field against a server-side allowlist before processing any JWT.

Common Assessment Errors

Only testing registration — Role misassignment may also be exploitable in profile-update, team-invitation, and OAuth scope-request endpoints; test every flow that modifies user attributes.
Skipping the none-algorithm test — Many libraries have patched this, but some older or embedded JWT implementations still accept it; always test regardless of expected framework support.
Not checking /jwks.json — The RS256 → HS256 algorithm confusion attack requires the server's public key; always check the JWKS endpoint before concluding that RS256 tokens are uncrackable.
Forgetting group/role inheritance — SaaS platforms with organizational hierarchies often have complex role inheritance logic; methodically test every group membership combination.
Treating JWT expiry as a security control — A forged JWT with a far-future exp claim will pass expiry checks if the signature is accepted; JWT forgery attacks do not require working within the original token's validity window.
Missing race conditions — Role transitions (trial activation, admin impersonation, permission grants) may be exploitable in sub-second windows; use concurrent request tools such as Burp Suite Turbo Intruder to test timing-sensitive role transitions.

NICE Framework Alignment

Code	Knowledge/Skill/Task Statement	How This Card Develops It
K0007	Knowledge of authentication, authorization, and access control methods	Covers role assignment mechanisms, JWT-based role encoding, and the failure modes of client-controlled role assignment
K0065	Knowledge of policy-based and role-based access control	Explains RBAC enforcement requirements and how role misassignment undermines the role hierarchy
K0070	Knowledge of common application vulnerabilities	Deep-dives JWT algorithm confusion, none-algorithm bypass, and weak secret cracking as concrete vulnerability techniques
S0001	Skill in conducting vulnerability scans and recognizing vulnerabilities in security systems	Practises role injection in registration, JWT tampering, hashcat secret cracking, and algorithm confusion attacks
T0028	Task: Identify systemic security issues based on vulnerability and configuration data	Develops ability to recognise insecure role assignment as a systemic RBAC failure across registration, tokens, and group membership