Introduction
This case perfectly reflects what we face every day in our work as pentesters. A host running a MariaDB database that required no authentication caught my attention during a recent network infrastructure test. This initial finding prompted me to investigate a web application on the same machine with intense focus.
The fact that any potential credentials from the database didn’t work for the web application’s login page pushed me then to analyze the application’s own code more deeply. It was here that I uncovered a critical vulnerability: the application’s login mechanism was handled entirely on the client-side, with administrator credentials hardcoded directly into a static JavaScript file (sic!).
This flaw allowed any user with network access to the application to retrieve the administrator password simply by inspecting the application’s source files. This effectively granted unauthenticated users full administrative control over the system, allowing them to add, edit, and delete content at will.
About the Vulnerability
The core of this vulnerability lies in a fundamental misunderstanding of web security principles: never trust the client. The application was built using a modern frontend framework (React/JS), but its authentication logic didn’t communicate with a secure backend server to verify credentials. Instead, when a user entered a password, the browser’s JavaScript would simply check if the input matched a constant string value stored within its own code.
Since browsers need to download all JavaScript files to run a web application, this “secret” password was freely available to anyone who opened their browser’s developer tools or downloaded the file directly.
Step-by-Step Exploitation
Locating the Credentials
The first step was to identify the static assets being loaded by the application. By inspecting the network traffic or the page source, I located a specific JavaScript file: main.96efcb33.chunk.js.
Downloading and examining this file revealed the application’s client-side logic.
Analyzing the JavaScript File
Inside the minified JavaScript code, a simple conditional check was responsible for handling the login. The code compared the user’s input (t) against two hardcoded strings, one for an editor and one for an administrator:
The text in quotation marks above, consisting solely of the letter X, turned out to be the passwords of the administrator and editor. Therefore, by reading these values directly from the code, I obtained the plaintext administrator password.
Achieving Full Control
With the discovered password, I navigated to the login page and authenticated successfully as “Admin”:
Final Notes
This case is a textbook example of how a single insecure development practice can completely compromise an application. The vulnerability was deemed critical because it provides a direct, low-effort path to full administrative control for any anonymous user. If combined with other potential flaws, such as an unrestricted file upload capability, this access could easily lead to a full server takeover.
My recommendations for the client are straightforward and essential for any secure web application:
Immediately remove all hardcoded credentials from the frontend source code and implement a proper server-side authentication system (e.g., using JWT, sessions, or integrating with LDAP/AD).
Passwords must be stored securely on the backend, never in plaintext. They should be processed with a strong, one-way hashing algorithm like bcrypt, scrypt, or Argon2.
