Testing for Injection Vulnerabilities

SQL injection: error, boolean, and time-based

Start with the single-quote test to break the query syntax (an error or changed response is a signal). Error-based: the database error reveals injection. Boolean-based blind: ' AND '1'='1 returns the normal page, ' AND '1'='2 returns a different one, so the app leaks one bit per request. Time-based blind: inject a sleep (database-specific) and measure whether the response is delayed, useful when there is no visible difference at all. Each technique extracts data when the previous one is not available.

XSS: reflected, stored, and DOM

Cross-site scripting runs attacker JavaScript in a victim's browser. Reflected: your input is echoed into the response unsanitized (test by injecting a unique marker and searching for it in the response, then a payload like <script>alert(1)</script> or a context-appropriate variant). Stored: input is saved and later shown to others (more dangerous). DOM-based: client-side JavaScript writes your input into the page unsafely. Always check where and how your input appears in the response to choose the right payload.

Command injection

If user input reaches a shell command, you can run OS commands. Test by appending shell metacharacters: ;id, |whoami, &&whoami. If there is no visible output (blind), use a time delay (; sleep 10) or an out-of-band technique (force a DNS/HTTP callback) to confirm. Command injection is high severity because it often means full server compromise.

XXE and SSTI

XXE (XML External Entity) injection happens when an app parses XML and processes external entities; in a request with an XML body or Content-Type: application/xml, you define an entity that reads a local file or makes a request, exfiltrating data. SSTI (Server-Side Template Injection) happens when user input is rendered by a template engine: the {{7*7}} test returning 49 confirms it, and SSTI frequently escalates to remote code execution depending on the engine. Both require recognizing the data format the app uses.

Lab: confirm injections manually

Use PortSwigger labs, Repeater only for confirmation.

1. 1

   1. Complete three SQL injection labs: one error/visible, one boolean-blind, one time-based blind.

2. 2

   2. Complete two XSS labs: one reflected, one stored.

3. 3

   3. For each, confirm the vulnerability in Repeater before using any other tool, and note the response signal that proved it.

4. 4

   4. Write the root cause (untrusted input reaching an interpreter) and the fix (parameterized queries / output encoding + CSP / safe APIs) for each class.

A parameter shows no visible difference for any input, but injecting a database sleep delays the response. Which technique confirmed the SQLi?

Pick one.

Common mistakes only experienced testers catch

Trying one XSS payload and giving up instead of matching the payload to the injection context (HTML body vs attribute vs JavaScript). Missing blind SQLi because you only looked for errors. Not URL-encoding payloads where required. Forgetting the {{7*7}} SSTI probe on template-driven pages. Treating command injection as low severity (it is usually critical). Reporting injection without the parameterized-query/encoding fix.