Web Security — Attacks on Websites

What you'll learn

• The two most famous web attacks: SQL Injection and XSS
• CSRF — tricking a logged-in user's own browser into acting against them
• Why they happen: mixing data with code
• How to detect and prevent them
• A real breach caused entirely by SQL injection
• You'll write a real input-sanitizer and a CSRF-token checker

⚠️ Ethics first: these techniques are for defending systems and testing your own (or authorized) applications. Attacking systems you don't own is a crime.

The root cause: data treated as code 💉

Almost every web attack is the same mistake: the app takes user input and accidentally runs it as instructions.

SQL Injection. A login form builds a database query by gluing your input into a string:

"SELECT * FROM users WHERE name = '" + input + "'"

Type a normal name and it's fine. But type ' OR '1'='1 and the query becomes:

SELECT * FROM users WHERE name = '' OR '1'='1'

'1'='1' is always true → it returns every user, bypassing the login. The fix: parameterized queries (a.k.a. prepared statements) — the input is sent separately from the query, so it can never become code.

XSS (Cross-Site Scripting). A site shows user input on the page without cleaning it. An attacker posts a "comment" like:

<script>steal(document.cookie)</script>

When other users view the page, their browser runs that script — stealing their session. The fix: escape output — turn < into < so the browser shows it as text, never runs it. (This lesson platform's own code runner uses a sandboxed iframe for exactly this reason.)

The golden rule: never trust user input. Validate it, escape it, and keep data and code strictly separated.

CSRF — hijacking your browser's trust 🎯

SQLi and XSS trick a server or exploit trust in user input. CSRF (Cross-Site Request Forgery) is different: it tricks the victim's own browser, using a trust the server has in that browser's cookies.

Here's the attack: you're logged into yourbank.com (your browser holds a valid session cookie). You then visit a malicious page that contains:

<img src="https://yourbank.com/transfer?to=attacker&amount=1000">

Your browser automatically attaches your yourbank.com cookies to any request to that domain — including this sneaky one hidden in an <img> tag. If the bank's server only checks "does this request have a valid session cookie?", it can't tell the difference between you clicking "transfer" on purpose and your browser being tricked into firing the same request on a stranger's page. This is called the "confused deputy" problem — your browser (the deputy) is confused into misusing its own authority.

The fix: CSRF tokens. The server embeds a random, secret, one-time token in its own forms. A real request from the bank's own page includes that token; a forged request from an attacker's page has no way to know it. The server rejects any request missing a valid, matching token.

Real-world case study: TalkTalk (2015) 🔍

In 2015, UK telecom provider TalkTalk suffered a breach exposing the personal data of nearly 157,000 customers — names, addresses, bank details for some — after attackers used SQL injection against a legacy webpage the company had reportedly forgotten was still running. The vulnerability was in code that, by some reports, was over a decade old.

The cost wasn't just technical: TalkTalk was fined £400,000 by the UK's data protection regulator (the largest such fine at the time) and reportedly lost tens of thousands of customers. The root cause was exactly the pattern from this lesson: user-controllable input reaching a database query, unguarded by parameterized queries — the same class of bug you just learned to prevent.

Summary

• SQLi and XSS both come from mixing untrusted data with code
• CSRF abuses the victim's own trusted browser session — fixed with unpredictable tokens
• Fix SQLi with parameterized queries; fix XSS by escaping output; fix CSRF with tokens
• You built a real escape_html sanitizer and a CSRF-token validator
• TalkTalk (2015) shows the real financial cost of an unpatched SQL injection flaw
• Study the OWASP Top 10 (Resources tab) — the industry checklist of web risks

Next: SOC Analysis — monitoring and responding to attacks in a real security team.