Threat Model: 0xj4f/genesis

[0xj4f]

Final Validation - Threat Model

Executive Summary (re‑written)

The Genesis IAM service uses FastAPI for the back‑end API and a Vue 3 SPA for the front‑end. Authentication relies on JWTs signed with a symmetric HS256 key that is hard‑coded by default and taken from the environment at runtime. The API is exposed with a wild‑card CORS policy (origins = ["*"]) and no rate‑limiting or request‑size limits on the login, token‑refresh and profile endpoints. All audit information is written only to the console; there is no persistent, tamper‑proof log store. The codebase contains a plain‑text example environment file that reveals the expected database‑credential format. Because the JWT secret is static and algorithm choice is user‑configurable, an attacker who learns the secret (or forces an algorithm downgrade) can forge or modify tokens, obtain arbitrary sub/user_id claims and thereby escalate privileges or replay tokens. Refresh tokens are accepted repeatedly without revocation, enabling unlimited token‑generation attacks. Finally, the application prints raw tokens and user identifiers to stdout, leaking sensitive material to any entity that can read the process output.

These findings constitute the validated and partially validated threats listed below. All other threat statements from the original drafts were either unsupported by the current code or duplicated. New, critical issues discovered during review have been added (e.g., lack of request‑size limits, token leakage via logging).

---

Consolidated Threat List (only VALID / PARTIAL entries)

ID	STRIDE	Status	Evidence (file / snippet)
S‑01	Spoofing	VALID	app/auth/auth.py – default secret: SECRET_KEY = os.getenv("OAUTH_SECRET_KEY","0f2883258b3c2cb9e21f1bdc827eafb9b7ad5509bf37103f82a1abab9109c65a")
S‑02	Spoofing	VALID	app/routes/auth.py – /token endpoint accepts username/password without throttling.
S‑03	Spoofing	VALID	Same hard‑coded secret as S‑01 (exposes signing key).
T‑03	Tampering	VALID	If the secret is known, an attacker can create forged JWTs with arbitrary sub/user_id. (See S‑01 evidence.)
T‑04	Tampering	VALID	app/main.py – CORS configured with a wildcard: origins = ["*"]
R‑01	Repudiation	VALID	app/main.py – only console logging: logging.basicConfig(level=logging.INFO) (no persistent audit log).
R‑02	Repudiation	VALID	Same as R‑01 – logs reside on the same host and can be altered or deleted.
I‑02	Information Disclosure	VALID	app/auth/auth.py – hard‑coded JWT secret visible in source.
I‑03	Information Disclosure	VALID	.env.example shows DB credential pattern (MYSQL_DEV_USER=dev, MYSQL_DEV_PASSWORD=devpassword).
I‑04	Information Disclosure	VALID	Open CORS (origins = ["*"]) lets any site read API responses, potentially exposing user data.
I‑05	Information Disclosure (new)	VALID	app/auth/auth.py prints token and username to stdout: print(f"token: {token}") and print(username).
D‑01	Denial‑of‑Service	VALID	/token endpoint has no rate‑limit, allowing credential‑guessing or request flood.
D‑03	Denial‑of‑Service	VALID	/refresh_token accepts any presented refresh token repeatedly; no revocation list or usage count.
D‑04 (new)	Denial‑of‑Service	VALID	Profile routes (/profile/ POST, PUT, DELETE) accept unlimited request bodies; FastAPI defaults have no size caps.
E‑03	Elevation‑of‑Privilege	VALID	app/auth/auth.py – algorithm configurable: ALGORITHM = os.getenv("OAUTH_ALGORITHM","HS256"). Setting it to none or a weak algorithm defeats signature verification.

Notes on excluded items

• T‑01 (SQL injection) – all DB access uses SQLAlchemy ORM with parameterised queries; no raw SQL present → INVALID.
• T‑02 (profile tampering/IDOR) – profile endpoints operate only on the authenticated user (/me/) and ignore any supplied user_id → INVALID.
• I‑01 (validation‑error leakage) – FastAPI’s default validation errors are not overridden in code; no explicit evidence of excessive detail → INVALID.
• E‑01 / E‑02 (admin role / privilege escalation via disabled accounts) – the application has no admin role and provides no endpoint to reactivate a disabled user → INVALID.

---

Recommendations (derived from the validated threats)

1. Remove the hard‑coded JWT secret and load it exclusively from a protected secret store; rotate regularly.
2. Fix the CORS policy – replace ["*"] with an explicit whitelist of trusted origins.
3. Enforce strict algorithm selection – hard‑code ALGORITHM = "HS256" (or switch to asymmetric RS256) and reject any none or weak algorithms.
4. Add rate‑limiting (per IP / per account) on /token and /refresh_token endpoints.
5. Implement refresh‑token revocation (store jti, make refresh tokens single‑use, provide revocation endpoint).
6. Introduce persistent, tamper‑evident logging (e.g., write‑once files, external SIEM) for authentication and token events.
7. Sanitize and limit request payload sizes on profile creation / update to mitigate DoS.
8. Delete or protect .env.example and any other files that expose credential patterns before release.
9. Remove debug print statements that emit tokens or usernames; use structured logging at appropriate levels.
10. Consider adding role‑based access control (admin vs. user) if future privileged operations are required.

By addressing the above items, the most severe and exploitable weaknesses in the current codebase will be mitigated.