Introduction

The challenge presents a student portal where our objective is to modify the grades of a student named "Natasha" to help her attend a camp.

None

Initial Access: SQL Injection

I started with an automated scan using sqlmap:

sqlmap -u "https://.../login" --data="username=admin&password=password" --method=POST --ignore-code=401 --batch

Due to persistent HTTP 401 errors, sqlmap failed to identify the vulnerability. Switching to manual testing, I successfully bypassed the login screen using a classic SQL injection payload:

' OR 1=1 #

Analyzing the Session and Token

Once logged in as rhonda.daniels, I noticed a token cookie. Decoding it revealed a Base64-wrapped SHA-512 hash. While I attempted to forge a token for "Natasha" or "Admin", the server-side validation was robust enough to prevent simple hash substitution.

None

Exploiting Client-Side Logic Digging into the source code, I analyzed assets/js/app.min.js. I discovered that the application relied on a global JavaScript object to determine user permissions. I performed a Client-Side Authorization Bypass by executing the following in the browser console:

staff.admin = true;

setupLinks();

This enabled the "Edit" functionality across the student table by re-binding the event listeners.

Insecure Direct Object Reference (IDOR)

Clicking a student link redirected me to /update-student/[Base64_ID].

None

Since Natasha was not in the initial list, I manually crafted an IDOR payload:

  • Encoded Natasha_Drew into Base64: TmF0YXNoYV9EcmV3.
  • Navigated directly to: /update-student/TmF0YXNoYV9EcmV3.

Final Flag Extraction

I accessed Natasha's private grade modification form, changed all grades to "A", and submitted the form. The server responded with the flag.

Prevention & Remediation (How to Secure the Application)

To prevent the vulnerabilities exploited in this challenge, the following security best practices should be implemented:

  1. Mitigating SQL Injection (SQLi)

The authentication bypass was possible because user input was directly concatenated into the SQL query.

  • Solution: Use Prepared Statements (Parameterized Queries). This ensures that user input is treated as data, not as executable code.

2. Enforcing Server-Side Authorization (Broken Access Control)

The most critical flaw was relying on a client-side JavaScript variable (staff.admin) to grant administrative privileges.

  • Solution: Never trust the client. Authorization checks must be performed on the server-side for every request. Before rendering a sensitive page or processing an update, the server must verify the user's session and their specific roles/permissions in the database.

3. Protecting Against IDOR (Insecure Direct Object Reference)

The application allowed access to any student's record simply by changing the Base64-encoded ID in the URL.

  • Solution: * Object-Level Access Control: The server should check if the currently logged-in user has the explicit right to view or edit the requested student_id.

4. Secure Session Management

The use of a weak, predictable token format (Base64 + Hash) makes the application vulnerable to session hijacking and forging.

  • Solution: Use industry-standard session management tools like JWT (JSON Web Tokens) with strong signing algorithms (e.g., RS256) or secure, random, server-stored session cookies. Ensure cookies are set with HttpOnly and Secure flags.