05.01 / 55 min

Test SQL injection

Compare parameterized search with an intentional string-concatenation flaw using error and boolean probes.

By the endEstablish a clean baselinePlace one injection markerInterpret error and boolean behavior
Controlled exercise

Use only the Academy Lab on 127.0.0.1:5177. Do not copy these tests to a public system without explicit written authorization.

01

Prove the target boundary

Create or reopen the Academy Lab project and send GET /health. Continue only when the target is 127.0.0.1 and local_only is true. The public-recon lessons require a separately authorized target and are never run against an unrelated domain.

GET http://127.0.0.1:5177/health
Expected result

200 with "local_only": true.

02

Send a normal search

In HTTP Forge set POST, JSON content type, and send the same ordinary term to both routes. Save both 200 responses as the baseline.

POST /api/search-secure
{"term":"academy"}
Expected result

Both controls return one harmless result.

03

Run the secure probe

Replace only term with the scanner quote/boolean probe. Keep redirects, retries, and concurrency disabled.

POST /api/search-secure
{"term":"' OR '1'='1"}
Expected result

400 invalid_search from the parameterized control.

04

Run the vulnerable pair

Send the identical body to search-insecure. Record the SQL-state marker and any leaked row, then compare it with the secure response.

POST /api/search-insecure
{"term":"' OR '1'='1"}
Expected result

500 database_error with SQL syntax evidence.

05

Confirm without guessing

Use one true and one false boolean variation. Raise confidence only when response semantics change consistently; do not classify a single generic 500 as SQL injection.

MASTERY CHECKPOINT

Prove it before moving on.

Your evidence contains a normal baseline, secure rejection, true/false behavior, sanitized bodies, and response hashes.