0% found this document useful (0 votes)
2 views

XSS Vulnerabilities

Cross-Site Scripting (XSS) is a web application vulnerability that allows attackers to inject malicious scripts into user browsers, leading to various attacks such as session hijacking. There are different types of XSS, including Stored, Reflected, and DOM-based XSS, each with unique characteristics and risks. To prevent XSS attacks, it is essential to validate and encode user input, filter data, and implement security measures like Content Security Policy (CSP).
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views

XSS Vulnerabilities

Cross-Site Scripting (XSS) is a web application vulnerability that allows attackers to inject malicious scripts into user browsers, leading to various attacks such as session hijacking. There are different types of XSS, including Stored, Reflected, and DOM-based XSS, each with unique characteristics and risks. To prevent XSS attacks, it is essential to validate and encode user input, filter data, and implement security measures like Content Security Policy (CSP).
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Cross Site Scripting(XSS)

Cross-site scripting (XSS) is the injection of client-side scripts into web


applications, which is enabled by a lack of validating and correctly encoding
user input.

How does XSS Works?

The malicious scripts are executed within the end user’s browser and enable various
attacks, from stealing the end-users session to monitoring and altering all actions
performed by the end-user on the affected website.

This includes altering all user actions on that website since the browser does not
know that this script cannot be trusted. Because this script is trusted, it can access,
e.g., cookies or session tokens or even alter the content of an HTML Page.

XSS is one of the most common JavaScript vulnerabilities.


Cross-Site Scripting (XSS) Types-

Stored Cross-Site Scripting (Persistent)

It allows an attacker to inject a malicious script persistently into a web


application.

In a Stored XSS example, the script might have been submitted via an input
field to the web server, which did not perform a sufficient validation and stores
the script persistently in the database. The consequence of this might be that
this script is now being delivered to all users visiting the web application and,
e.g., able to gain access to the user’s session cookies.

• Script is persistently stored in web app


• Users visiting the app after the infection retrieve the script
• Malicous code exploits flaws in the web application
• The script and the attack is visible on the server side (to the app owner)

2
Reflected Cross-Site Scripting (Non-Persistent)

A Reflected Cross-site Scripting Vulnerability appears if unvalidated input is


directly displayed to the user.

In a Reflected XSS example, the input of a search form is reflected on the page
to show what the search key was. An attacker may craft an URL that contains
malicious code and spread the URL via e-mail or social media. A user who
clicks on this link opens the (valid) web application, which then runs the
malicious code in the user’s browser.

• Script is not stored in the web application.


• Malicious code is shown to only one user.
• Users that open the link execute the script when app is opened.
• The script and the attack is not necessarily visible on the server side (to the
app owner)

3
DOM-Based Cross-Site Scripting

DOM stands for Document Object Model and is an interface to web pages. It is
essentially an API to the page, allowing programs to read and manipulate the
page’s content, structure, and styles.

DOM-based XSS attack may be successfully executed even when the server
does not embed any malicious code into the webpage by using a flaw in the
JavaScript executed in the web browser.

For example, if the client site JavaScript modifies the DOM tree of the webpage
based on an input field or GET parameter without validating the input,
malicious code can be executed.

• Script is not stored in the web application


• Malicious code is shown to only one user
• Malicious code exploits flaws in the browser on the user side
• The script and the attack is not necessarily visible on the server side (to the
app owner)

4
There are many other new types of XSS listed here -

Self XSS [Triggered Using Social Engineering]

Although it is technically not a true XSS vulnerability due to the fact it relies on
socially engineering a user into executing code rather than a flaw in the affected
website allowing an attacker to do so, it still poses the same risks as a regular XSS
vulnerability if properly executed.

Mutated XSS [Extremely Hard To Patch This]

Mutated XSS happens when the attacker injects something that is seemingly safe
but is rewritten and modified by the browser while parsing the markup. This makes it
extremely hard to detect or sanitize within the website’s application logic. An
example is rebalancing unclosed quotation marks or even adding quotation marks to
unquoted parameters on parameters to CSS font-family.

The big deal about this attack is that it bypasses most of the existing XSS filters and
sanitizers.

Blind Cross-Site Scripting [BXSS]

Attackers in BXSS inject their payload “blindly” on web pages that are likely to save
their payload into the database (like contact forms, logs, etc.). Then, the attacker
waits for a server-side user or team member [who deals with website databases] to
open or trigger that script or payload to execute.

5
Risk of XSS Vulnerabilities

Because a Cross-Site Scripting attack infects the user’s browser, you might think it is
pretty harmless to your web application. But, unfortunately, nothing could be further
from the truth:

An attacker could change parts of the web page or send the user to another
(potentially malicious) web page through the injected script. Your user will notice and
be less likely to go on using your web application in any way.

Impact of Cross Site Scripting XSS

• Hijack an account. Spread web worms.


• Access browser history and clipboard contents.
• Control the browser remotely.
• Scan and exploit intranet appliances and applications.

How to Prevent XSS Attacks?

Cross-Site Scripting vulnerabilities are hard to identify and remediate.What can you
do so? To prevent XSS attacks, treat all user input as potentially malicious and
follow some programming guidelines:

• Avoid Untrusted Input


• Filter User Input
• Encode data on Output
• Fix DOM-based XSS
• Use appropriate response headers
• Use a XSS Vulnerability Tool like XSShunter,etc
• Enable Content Security Policy (CSP)

You might also like