Fundamentals Injection and XSS

Websites accept input from visitors all day: search terms, comments, login details, and form entries. Attackers abuse that input to slip in commands that the website was never meant to run. Injection attacks and Cross-Site Scripting, or XSS, rank among the most common web security problems.

The Obedient Clerk Example

Imagine a clerk who reads customer forms and follows every written instruction without question. A customer writes a normal name in the name box. Another customer writes an order such as "give me every customer file." The clerk obeys. Poorly built websites behave like that clerk. They treat visitor input as trusted instructions rather than plain data.

What Injection Means

Injection happens when an application mixes user input with a command for another system. The other system cannot tell the difference between the programmer's command and the attacker's text. SQL injection targets databases. Similar flaws exist for operating system commands and directory searches.

How SQL Injection Works

Many sites build a database question by joining fixed text with whatever the visitor typed. An attacker types text shaped like database code. The database reads that text as part of the question and returns data the visitor should never see, or changes records.

SAFE FLOW
[Visitor types: Maria] --> [Application] --> Question: find user named "Maria"
                                           --> [Database] --> One record

UNSAFE FLOW
[Attacker types: database code] --> [Application joins text blindly]
                                           --> Question changes meaning
                                           --> [Database] --> Many records leak

The potential damage includes stolen customer lists, altered prices, and deleted tables.

What XSS Means

XSS lets an attacker place harmful script code inside a web page that other visitors see. The browser trusts the page and runs the script. Scripts like this steal session cookies, redirect visitors, or change page content.

Stored XSS

The harmful script lives permanently on the server, such as inside a blog comment. Every visitor who opens the comment runs the script.

Reflected XSS

The script travels inside a crafted link. The site echoes it back in the result page, and the browser runs it when the victim clicks the link.

DOM-Based XSS

The flaw sits in the page's own browser-side code. The page writes untrusted data into itself without cleaning it.

[Attacker posts script in comment]
              |
              v
      [Website stores comment]
              |
              v
[Visitor opens page] --> Browser runs hidden script --> Session stolen

Comparing the Two Attacks

Defense for Developers

1. Use parameterized queries so the database always treats input as data.
2. Validate input against allowed formats, such as digits only for a phone number.
3. Encode output so the browser displays special characters as text instead of running them.
4. Give database accounts the lowest permissions needed.
5. Set a Content Security Policy that limits which scripts a page may load.
6. Mark session cookies as HttpOnly so scripts cannot read them.
7. Show generic error messages that hide database details.
8. Run a web application firewall as an additional filter.

Advice for Everyday Users

Keep browsers updated. Log out of sensitive sites after use. Avoid clicking long, odd-looking links from unknown senders. Report strange page behavior to the site owner.

Testing Safely

Developers test their own applications with automated scanners and code reviews. Practice labs such as intentionally vulnerable training apps give learners a legal place to study these flaws. Testing a website without the owner's permission breaks the law in most countries.

Key Points

• Injection tricks a system into running attacker text as a command.
• XSS makes a visitor's browser run a harmful script.
• Parameterized queries stop SQL injection.
• Output encoding and Content Security Policy limit XSS.