This first part of the series dives into how VulnBank’s login and access‑control layers can be completely subverted through a mix of SQL injection, weak JSON Web Token handling and broken authorization checks. Starting from the public login page, it shows how poorly written queries allow attackers to bypass authentication, how insecure JWT signing and storage make tokens easy to forge or replay, and how missing server‑side validation turns “secure” sessions into a fiction.

SQL Injection in Login Page

Without saying too much, I would just setup my burp suite and foxy proxy to intercept traffic and test if it is vulnerable to SQL injection

First thing I would do is to register a user since I do not have any previous username that I could try SQL injection on

now that we have a registered user, let us try to bypass authentication and gain access to the account without the password

As seen above, we have captured the request and what is left is to send to repeater to test for SQLi

As seen above, with the help of a simple ' OR '1'='1 payload, we were able to bypass authentication for the userrr

Let us go a step further and try to bypass the authentication for the admin user to see if we can get access to an account with elevated privileges

Voila, we have successfully compromised admin account via authentication bypass with SQLi payload.

REMEDIATION: - Implement parameterized queries (prepared statements) for all database interactions to ensure user input is never executed as code.

Weak JWT Implentation

In this section, we would be trying to test if there is weak implementation in the Json Web Token (JWT)

As usual, I captured the request again so I can have the token as seen below

In testing for weak JWT implementation, my go to tool has always been xjwt

From the screenshot above, we can see that there is a whole lot of things wrong with the JWT token

The main issues found by the scanner are listed below:

  • VulnBank’s JWTs use a weak HMAC secret (secret123), allowing attackers to forge arbitrary tokens that the server will accept as valid.
  • The tokens lack an exp claim, so they never expire and can be replayed indefinitely once stolen or forged.
  • Symmetric HMAC signing with a shared secret means that compromising any one service or environment exposes all JWT‑protected services that trust the same key.
  • The absence of an aud claim allows the same JWT to be reused by unintended consumers, enabling cross‑service token replay.
  • Without an iss claim, the application cannot reliably verify which issuer created a token, weakening both trust and auditability of JWTs.​

Since we have identified that they are critical issues, I would try to elevate the privilege of the user (r3d_z3e) to an admin user

As seen, the user is just a normal user with low privilege.

The next step is getting the jwt token (there are many ways to do this either by intercepting traffic or by using dev tools but I am going to be making use of the dev tools)

Now this token is what we are going to editing to elevate privileges

The first thing to do is to get the secret key as seen below

as this done, we can now regenerate another JWT to elevate privileges

Now that we have the generated token, we shall be replacing it with the former and refreshing the page to elevate the privilege the user

As seen from the screenshot above, the user (r3d_z3e) now has admin privileges and features that a normal user would not be able to access normally

REMEDIATION: Strengthen security by using a cryptographically strong secret (HS256) or asymmetric keys (RS256) and enforcing expiration (exp) and audience (aud) claims.

Broken object level authorization (BOLA)

In testing for this vulnerability, we shall be creating 2 account for this

Now that we have both account created, we would be transferring accounts to each of the account in order to have a transaction history and have an id parameter to test

The next step is to login into user A (r3d_z3e) and initiate transfer to user B(# Feranmiiiiiiiiiiii) and also vice versa (as seen below)

Now that we have transactions history, what we are going to be testing next is trying to access transaction history of another user while authenticated as a different user i.e while being authenticated as User A can we access the transaction history of user B

Now we are going to be intercepting the transactions endpoint and moving from there

As seen above I have gotten the transaction history for the user I am logged into, the next thing I would be trying is to see the transaction history of the user that I have sent money to or I received money from in my transaction history since account number is what is needed to access the transaction history.

Lo and behold, we could get the whole transaction history of another user while not being authenticated to that user

What this just shows us is that the API failed to enforce object-level authorization. It trusted that any user who sends a valid token could access any account’s transactions, as long as they knew the account ID.

REMEDIATION: Enforce server-side ownership validation to ensure the authenticated user has explicit permission to access the specific account ID requested.

Broken object property level authorization (BOPLA)

Broken Object Property Level Authorization (BOPLA) is an API security vulnerability where insufficient authorization checks allow unauthorized users to view or modify specific properties within a data object such as changing their role to “admin” even if they should not have the permission to do so.

Broken Object Property Level Authorization (BOPLA) is a single vulnerability that combines two flaws:

  1. Mass Assignment – letting users modify sensitive properties (like isAdmin) they shouldn’t be allowed to change.
  2. Excessive Data Exposure – returning more data than needed, including private fields (like roles) in API responses.

Together, these create BOPLA: attackers first see hidden properties (due to poor filtering), then abuse them (via unsafe input binding), leading to privilege escalation or data leaks.

From the above screenshot, it can be seen that after logging in that there is a case of excessive data exposure (roles) which helps us in our mass assignment

the next thing we would be attempting now is intercepting the traffic while trying to create a new user and use the parameter is_admin": true to escalate privileges

As seen above, we have been able to abuse the mass assignment vuln to escalate privileges, let us go ahead to login to see if what we have there has elevated privileges

As seen above, we have successfully exploited the BOPLA vuln to register BGS as an admin

REMEDIATION: Apply strict input allow-listing to prevent unauthorized modification of sensitive properties like user roles and administrative flags.

Weak Password Reset Mechanism

VulnBank’s password reset uses a simple 4-digit PIN (basically 10,000 guesses max) with no rate limiting or expiration, meaning anyone can request a reset for any account and just keep trying codes until one works. For a banking app where a successful guess means full access to someone’s money and transaction history, relying on a PIN you could brute-force over lunch is a recipe for disaster.

The first thing to do is to reset the pin as seen above, and intercept request

I would be sending this request to intruder afterwards to bruteforce the pin with a custom wordlist (0000-9999) that I created

First thing first, insert a payload marker in the pin part since that is what we are really interested in as seen below

Afterwards we chose our payload

After the payload is chosen, all is left is to start attack

And due to rate limiting not implemented, we finally got to bruteforce in few minutes and we got our password reset in few minutes as seen below

Now let us try to login with the new password to see what we have thereee

And there we could see that the attack was successful

REMEDIATION: Secure the reset process by implementing strict rate limiting on PIN attempts and replacing 4-digit codes with long, high-entropy alphanumeric tokens.