-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Issue 1: Insecure Authentication Token Design (Non-JWT, Unsigned Tokens)
Description
Authentication uses random opaque tokens stored directly in MongoDB instead of cryptographically verifiable JWTs.
def generate_token(user_id: str) -> str:
token = secrets.token_urlsafe(32)
tokens_collection.insert_one({...})
Impact
Tokens are not signed
No issuer, audience, or integrity verification
Token theft = full account takeover
Database leak = total authentication compromise
Authentication is a core trust boundary. Compromise enables unauthorized system-wide access, directly violating Build2Break SL-1 criteria .
Issue 2: Privilege Escalation via Token Replay & Role Trust
Description
Authorization trusts the current database role for any valid token without token invalidation or role binding.
if user.get("role") not in allowed_roles:
raise HTTPException(...)
Exploit Scenario
User logs in → receives token
User role is modified (or DB compromised)
Old token remains valid
Attacker gains Admin/Manager access
Impact
Privilege escalation
Unauthorized approvals / rejections
Full workflow compromise
Severity Justification
Unauthorized access to financial decision roles is explicit SL-1 under Build2Break rules .
Issue 3: Client-Controlled Credit Score & Risk (Financial Integrity Failure)
Description
The /loan/apply endpoint trusts client-supplied financial decisions:
loan_data.score
loan_data.risk
No server-side recomputation or validation occurs.
Exploit Payload
{
"score": 100,
"risk": "Low Risk ✅"
}
Impact
Loan eligibility can be forged
AI decision logic bypassed
Managers review manipulated data
This directly breaks financial correctness and trust, producing incorrect real-world outcomes, a core SL-1 condition .
Issue 4: Default High-Privilege Credentials Present
Description
The system documents and seeds default manager credentials:
username: manager
password: manager123
Impact
Immediate unauthorized Manager access
Loan approvals without verification
Violates secure deployment expectations
Rule Violation
Build2Break explicitly disallows hard-coded or default credentials in deployed systems .
Issue 5: Open CORS with Credentialed Requests
Description
allow_origins=["*"]
allow_credentials=True
Impact
Any external site can issue authenticated requests
Token-based CSRF-style abuse possible
Session misuse across origins