Cross-Site Scripting(XSS- A Web Application Vulnerability)

Cross-Site Scripting (XSS) is a web security vulnerability that occurs when a trusted website allows users to input malicious scripts. Because the browser views the script as legitimate, it executes it in the victim's browser. Attackers use XSS to steal cookies, hijack user sessions, or redirect users to phishing sites.

How XSS Works:

An XSS attack usually follows this sequence:

1. The Flaw: A web application takes user input and includes it in a webpage without properly validating or encoding it.
2. The Injection: An attacker injects a malicious script (usually in JavaScript) into the site.
3. The Execution: When unsuspecting users view the page, their browser runs the malicious script, trusting it comes from the website

Common Types of XSS

• Stored XSS (persistent XSS) : The malicious script is permanently saved on the target application's server (e.g., in a database or a comment section,forum post) and executes every time a user visits the affected page. In other words, When other users load the affected page, the script is automatically executed in their browsers.
• Example: A user submits a comment containing <script>alert('XSS')</script> and it gets saved. Every visitor sees and executes it.

Impact:

• Affects multiple users
• Can steal session cookies, credentials, or perform actions on behalf of users
• Very simple example (basic reflected XSS):

Another example,Suppose a site does: Hello, <b> USER_INPUT </b>

• You type: vedika → page shows: Hello, vedika (safe).
• You type: <script>alert(1)</script> → if not filtered, browser will execute this and show a popup.

Reflected XSS(Non-persistent): This happens when input is immediately returned by the server in the response.

• The malicious script is not stored; it is reflected in the response.
• Usually delivered via a crafted URL.
• example: https://example.com/search?q=
• If the site displays q without sanitization, the script executes.

DOM-Based XSS: The vulnerability exists in the client-side code rather than the server-side code, allowing the attacker to alter the webpage via Document Object Model (DOM) manipulation. The vulnerability exists in JavaScript code, not the server.

• The script modifies the DOM using unsafe input (e.g., document.location, innerHTML)

Example: document.getElementById("output").innerHTML =location.hash;

• document.getElementById("output"): Finds the specific HTML element on the page that has id="output" (like <div id="output"></div>).
• location.hash: Gets the part of the current page URL that contains the anchor/fragment (e.g., if your URL is ://example.com, it returns "#welcome").
• .innerHTML: Replaces the HTML content inside the target element with the hash value
• innerHTML renders whatever text is passed to it as raw HTML, it leaves the website vulnerable to Cross-Site Scripting (XSS).If an attacker tricks a user into clicking a link with malicious JavaScript in the hash (e.g., #<script>alert('account')</script>), the browser will execute the malicious script

Impact:

• No server interaction required
• Harder to detect with traditional server-side defenses.

**Get vs Post in XSS :**In XSS and web applications, GET and POST are HTTP methods used to send data between the browser and the server. They are not XSS types themselves, but XSS attacks can happen through both.

1.GET Method: Data(payload) is sent via URL.

eg: https://site.com/search?q=hello

Here:

• q=hello is parameter data
• It is visible in the URL

GET-based XSS Example

Vulnerable code: https://site.com/search?q=

If the website reflects the input directly, the script executes.

This is commonly related to Reflected XSS.

2. POST Method: Data is sent secretly in the HTTP body, not in the URL.(it is a stored xss example)

eg:

Data sent: username=admin&comment=hello(Not visible in URL.)

POST-based XSS Example: A comment form

Attacker submits: The application takes whatever is inside this <textarea> and sends it to the server to be saved in a database

Summary of Key Concepts

• Stored XSS (Persistent): The script is stored on the server and delivered to every visitor of the page.
• No Sanitization: The application failed to validate input or encode output, treating malicious scripts as harmless text.
• Outcome: The attacker can steal cookies, hijack user sessions, or redirect users to malicious sites.

How to Prevent This (Best Practices)

1. Escape Output: Before rendering data on a page, encode it. <script> should become <script> so the browser displays it as text instead of executing it.
2. Input Sanitization: Sanitize input to remove dangerous HTML tags.
3. Content Security Policy (CSP): Implement a policy to restrict where scripts can be loaded from and block inline scripts.