In the web-driven world of today, user interaction is crucial to almost every program. Websites constantly accept and handle user input, from comment sections to login forms. When this input is not adequately validated or sanitized, one of the most common security vulnerabilities that results is Cross-Site Scripting (XSS). Cross-site scripting, or XSS, is one type of web security vulnerability that lets hackers install harmful programs into trustworthy websites. Because it exploits the user's trust in the online application, XSS is particularly dangerous. The attacker targets users instead than the server directly by using the software as a delivery channel. In this blog, we will go over how XSS works, its several forms, its real-world impacts, and — most importantly — how to effectively block it.

What is XSS?

Cross-Site Scripting (XSS) is a web security vulnerability where attackers inject malicious client-side scripts (usually JavaScript) into trusted websites. When unsuspecting users visit the compromised page, the script executes in their browser, allowing attackers to steal session cookies, hijack accounts, or deface websites.

How does it works ?

Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application.

Types of XSS?

There are three main types of XSS attacks. These are:

Reflected XSS, where the malicious script comes from the current HTTP request.

Stored XSS, where the malicious script comes from the website's database.

DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

1. Reflected XSS:

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Checking for the if inputs gets reflected in the page source, body url

If input gets reflected we can hunt for reflected xss

Sending a simple javascript to execute and prove xss

No input validation or sanitization is dangerous

Basic Search Reflection

Vulnerable URL: https://example.com/search?q=store

Response: <p>You searched for: store </p>

Attack URL: https://example.com/search?q=<script>alert(2)</script>

Result: The browser executes

XSS in Limited Inputs:

· XSS in limited inputs

· How to do XSS if <Script> tags are blocked

Payload : <Script>alret(1)</script>

<img.Src = x.onerror = conform(1)>

XSS in Request Headers:

· We can do XSS by giving the arbitrary is payload in to the request headers

· If the application interpreted and executes it, then it will boom!

· You can choose any Request Header

· No Sanitization and taking decisions is dangerous

XSS in User agent and Caching Server Attacking Many:

· we attack the website using XSS in User Agent in the web application

· we will also save our payload into the Caching Server (MISS — HIT)

· Whenever anyone visits the url which is cached by the server will lead to XSS

· XSS will remain until Cached is flushed

XSS in Email login Fields:

· We attack the website using XSS In email Field in the web application

· According to RFC822 email address Validator we will make our payload , XSS will win!

XSS Protection-Bypass On XYZ Bank :

· We will bypass and XSS Where there is Improper Input Sanitization or HTML Encoding With limited inputs

· No proper Encoding or Escaping and taking decisions is dangerous

Ex: BANK

2. XSS Stored:

· Stored cross-site scripting (also known as second-order or persistent XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

· IF any application stores your inputs but in an unsafe manner

· Always try where you can save the input XSS Payload where the server saves the payload

Example:

3. DoM (Document Object model) Based XSS:

DOM-based XSS vulnerabilities usually arise when JavaScript takes data from an attacker-controllable source, such as the URL, and passes it to a sink that supports dynamic code execution, such as eval () or inner HTML. This enables attackers to execute malicious JavaScript, which typically allows them to hijack other users' accounts.

To deliver a DOM-based XSS attack, you need to place data into a source so that it is propagated to a sink and causes execution of arbitrary JavaScript.

Client side attack input comes into the Dom is source it gets executed through in the Dom Is Sink

XSS MOUSE:

· When Keyword input is blocked you can perform XSS using mouse

· Mouse payloads — Onmouseover, onmousemove, onmouseup, onmouseenter, onmouseleave, onmousewheel, onmouseout

· Effective in Bypassing many keyboard input checks and win

XSS Polyglots:

· Dictionary: Mutilingual (or) person who knows many languages

· Combining XSS Payloads leads to polyglots

· Effective in bypassing many input checks and win

XSS polyglots Breakdown:

XSS Exploitation-URL Redirection:

· We are Going to make the victim redirect to Evil website

· We will find a injection point burpsuite spider feature

· Inject the XSS Payload in the Param and boom!

XSS by Using Spider:

· IF we do not get a parameter directly from the application

· We will find a injection point using burpsuite spider Feature

· Inject the XSS Payload in the param and Boom!

Impacts:

· URl Redirection

· Phishing

· Cookie stealer

· File upload like SVG with script

XSS Mitigations:

· Input Sanitization

· Escaping-Encoding of all the input that a user ends

· Strong Input Validation for Limited inputs with sanitization

· WAF

· Filter input on arrival

· Encode data on output

· Use appropriate response headers

· Content security policy (Csp)

Conclusion:

One of the most prevalent and harmful flaws in contemporary web applications is Cross-Site Scripting (XSS). As we've shown, even a minor error, such as neglecting to verify or encrypt user input, might allow hackers to run harmful scripts in a user's browser. The consequences of Reflected, Stored, or DOM-based XSS can be dire, ranging from data theft and session hijacking to total account compromise. Because XSS takes use of user trust instead of assaulting the server directly, it is particularly dangerous.

Ultimately, security is a continuous process rather than a one-time event. Maintaining awareness, conducting frequent testing, and putting best practices into practice will assist guarantee that your applications continue to be reliable and safe for users.