Injection Attacks: SQL Injection and XSS

Security
43 / 47

Injection happens when untrusted input is glued into something that gets interpreted as code - a SQL query or a web page. The cure is to keep data and code separate (parameters and output encoding), not to hunt for bad characters.

The Analogy (Read This First)

A form letter that says 'Dear <name>'. If someone's 'name' is 'Bob. Also, transfer $500 to account 9', and the clerk follows everything in the letter, the data became instructions.

Deep Dive Analysis

SQL injection. Building a query by string concatenation lets the input rewrite the query:

# vulnerable
query = "SELECT * FROM users WHERE name = '" + name + "'"
# name = "x' OR '1'='1"  ->  WHERE name = 'x' OR '1'='1'   (every row)

The real fix: parameterised queries. The database receives the SQL text and the values separately, so a value can never become syntax:

cur.execute('SELECT * FROM users WHERE name = ?', (name,))

ORMs do this for you unless you drop to raw string building. Identifiers (table or column names) cannot be parameters: validate them against an allow-list.

Why sanitizing is the weaker defence. Stripping quotes or keywords fails on encodings, comments and database-specific syntax. A sanitizer is a backup layer (reject obviously invalid input, limit length, check type) but the parameter binding is what actually protects you. Also give the application's database account only the privileges it needs.

Cross-site scripting (XSS). If a site puts user input into HTML without encoding it, the browser runs injected <script> as if the site wrote it, with access to the user's session. Stored XSS saves the payload (a comment); reflected XSS echoes it from a URL; DOM XSS happens in client-side code.

The XSS fix: encode on output, for the context. Turn < into &lt; and quotes into entities in HTML; use proper encoding inside attributes, URLs and JavaScript. Frameworks like React escape by default - the danger is dangerouslySetInnerHTML and innerHTML. If you must allow rich text, run it through a maintained sanitizer with an allow-list of tags (for example DOMPurify).

Defence in depth for XSS. A Content-Security-Policy header restricts where scripts may load from; HttpOnly cookies stop scripts reading the session cookie; SameSite limits cross-site sending. None of these replaces correct encoding.

The principle. Treat every input as untrusted data, keep it in a data channel (bound parameters, escaped output) and never let it cross into the code channel. The same idea covers command injection, template injection and LDAP injection.

Key Bullets
  • Never build SQL by concatenating input; bind parameters.
  • Table and column names cannot be parameters: use an allow-list.
  • Filtering 'bad characters' is a weak, bypassable defence.
  • Encode output for its context (HTML, attribute, URL, JS) to stop XSS.
  • CSP, HttpOnly and SameSite reduce damage but do not replace encoding.
Trade-offs
Parameterised queries: robust by construction | Do not cover dynamic identifiersAllow-list validation: tight and predictable | Must be maintained as features growRich-text allowed: better editing experience | Needs a well-maintained sanitizer
Real-World Examples
A login form that returns every user for ' OR '1'='1A comment box that runs a script for every visitorA search page that echoes the query back unescaped

Curated Curation & Deep Insights

ScaleDojo Certified
Video Tutorial Pending

Our system architects are vetting high-quality, authorized video guides for Injection Attacks: SQL Injection and XSS with zero third-party platform links.

Verification in Progress
Reading Material Pending

We are preparing premium, zero-competitor deep-dives for Injection Attacks: SQL Injection and XSS. Authorized reading references will appear automatically.

Verification in Progress