A web application receives a request and returns a response. The request can contain a path, query parameters, headers, cookies, and a body. The response can contain a status code, headers, and content.
Security problems often appear when the server trusts request data without sufficient validation or authorization. Your first task is to understand the normal request and response.
Collect a baseline
- Open the challenge in your browser.
- Identify the pages and actions that the challenge provides.
- Use the browser developer tools to inspect network requests.
- Record the request method, path, status code, and important parameters.
- Repeat one normal action and confirm that you understand its result.
A baseline gives you a comparison. If you change an input later, you can compare the new response with the normal response.
Important web concepts
Input
Input is information that a user or another system sends to the application. Examples include search text, identifiers, filenames, form fields, and JSON values. A secure application checks input before it uses it.
Authentication and sessions
Authentication establishes an identity. A session lets the application remember that identity across requests. A cookie often carries a session identifier. Do not share a live session identifier because another person can possibly use it.
Authorization
Authorization decides what an authenticated identity can do. A challenge can ask whether one user can read or change an object that belongs to another user. In a real assessment, you need explicit permission and test accounts for this work.
Server-side and browser-side behavior
The server processes requests and controls protected data. Browser code controls the interface and can also create requests. A restriction in the interface is not the same as a server authorization check.
Test one variable at a time
Change one request value and compare the response with the baseline. Record differences in status, content, headers, length, and application state. If you change many values at the same time, you cannot know which change caused the result.
Authorized environments only: Use these methods on CTF systems, local training applications, or systems where the owner gave you clear permission.
Questions to ask
- What input does the server receive?
- What part of the response changes when the input changes?
- Does the server verify the user before it returns an object?
- Does the server verify the user's permission before it changes an object?
- Does the application handle special characters as data or as instructions?
- Can a filename, URL, or object identifier select an unintended resource?
Record useful evidence
Save the normal request, the changed request, and both responses. Explain the difference. A status code alone is not proof of a security effect. Confirm whether protected data was returned or whether a state change occurred.
Continue with the writeup guide to turn this evidence into a clear solution.