Cross-Site Scripting Demonstration Using Python Flask

Web-Application
XXX XXX
School of Engineering and Technology School of Engineering and Technology
Indiana University-Purdue University Indianapolis Indiana University-Purdue University Indianapolis
Indianapolis, Indiana Indianapolis, Indiana

Abstract – Cross-site scripting, also known as web application uses input from a user within the
XSS, is a known category of vulnerabilities that output it generates without validating or encoding
uses client-side coding to exploit websites, such as it.” XSS participants usually include the intruder
forums, messaging, search, and networking sites, (person intending to commit a crime and steal
requiring user input [6]. This code injection flaw sensitive data), web server (source of the vulnerable
occurs when malicious scripts are erroneously website), and victim (usually the intended targeted)
[6].
accepted as authorized because the website input
is not controlled, validated, or sanitized by the JavaScript is a popular client-side coding
application before it is processed. According to language leveraged by developers to make static
the OWASP (Open Web Application Standards websites more, lightweight, dynamic, and
Project) foundation [4], “Flaws that allow these responsive [11]. For this reason, it is commonly
attacks to succeed are quite widespread and occur used by evil intruders to execute XSS attacks. A
anywhere a web application uses input from a host environment, commonly the web browser, is
user within the output it generates without
required to run JavaScript [10]. The code is
validating or encoding it.” Participants include
processed locally (on the client-side) versus
the attacker, vulnerable website, and victim who
remotely (on the web server-side) for efficiency.
is usually being targeted for their sensitive data
JavaScript code is normally embedded between
[6].
HTML <script> tags, directly or indirectly, source
file or inline. However, a malicious cross-site script
Keywords – Cross-site scripting, XSS, JavaScript,
can be obscured in a URL (Universal Resource
Stored XSS, Reflected XSS, DOM-based XSS,
Locators) or hidden between other HTML opening
DOM, XHR, cookies, payload, security headers,
and closing tags.
filtering, encoding, escaping

I. INTRODUCTION
Cross-site scripting, also known as XSS, is a
known category of vulnerabilities that uses client-
side coding to exploit websites requiring user input,
such as forums, messaging, search, and networking
websites [6]. This code injection flaw occurs when
malicious scripts are erroneously accepted as
authorized because the website input is not
controlled, validated, or sanitized by the application
before it is processed. According to the OWASP Figure 1: HTML opening and closing tags
foundation [4], “Flaws that allow these attacks to
succeed are quite widespread and occur anywhere a
 Most host resources are restricted (e.g., download the malicious content and potentially be a
operating systems, local files), but JavaScript has victim of the intruders' malfeasance [7]. The
access to a considerable number of objects that keyword in this attack is persistent since the
increase its function. For example, the DOM attacker gets data continuously and repeatedly if the
(Document Object Model) is not JavaScript, but malicious script is never detected and removed from
JavaScript can use it like an API (Application the server [7]. A threat actor's code could remain on
the website indefinitely [5]. Future visitors could
Programming Interface) to structurally change most
have their browser or session compromised,
elements on an HTML page [10]. XMLHttpRequest resulting in the attacker stealing cookies and
(XHR) objects allow you to send HTTP (Hypertext swindling victims into divulging private data [5].
Transfer Protocol) requests to a remote server using The attacker could hijack accounts, impersonate
JavaScript [10]. XHR “is a dynamic API for client- users, create a keylogger using the victims' browser,
server data transfer [12].” Instead of resetting the mine information, turn on a camera, and perform
entire page in a web browser when a request is other improprieties [5].
made to the server, developers utilize XHR to
perform data transfers without a full page reload
[11]. Trusted Security [15] mentions that XHR is
convenient for an intruder since it can be set to run
in the background asynchronously [15]. It will not
be obvious to the victim that their browser is under
attack and the malicious requests are being sent
[15].

XSS is not limited to JavaScript but can

include other scripting languages. Javascript is the
focus of this project since most websites (over 97%) Figure 2: CISSPAnswers | Stored XSS (Cross-site Scripting)
use it and many could be vulnerable [1]. For
example, in 2018, British Airways experienced a In a Reflected XSS attack, the “malicious
breach, that was caused by a Stored XSS script is part of the victim's request to the web
vulnerability in the payment form of their website. application, which is then reflected back by the
application in form of the response [6].” The
Credit card numbers and other personal data were
keywords in this attack are request and response.
captured by the intruders [2]. XSS is a widely used
The server response may be informational,
web attack with many exploit possibilities, so we server/client error-related, search result or any other
believe it is worth studying and demonstrating. output sent as a response to the request. "The
victim's browser accepts it, assuming it to be a
The three main categories of cross-site legitimate part of the web page and executes it as
scripting include Stored, Reflected, and DOM- the page loads [6].” In Reflected XSS cases, the
based. Stored XSS (Persistent) requires a malicious victim clicks a link received by phishing e-mail
script to be injected within the website's storage, message or the link could be published on another
usually the database [9]. "Persistent XSS is website [6]. URL shortening services, such as
considered to be more serious than other XSS flaws, TinyURL or Bitly, can make suspicious links harder
as the attacker's malicious script is injected into the to detect since they are masked [9].
victim's browser automatically. It does not require a
phishing attack to lure the user into clicking on a
link [6].” Once the injected code is on the server,
each subsequent website visitor will automatically
 Figure 3: CISSPAnswers | Reflected XSS (Cross-site
Scripting) Figure 5: Improving Your Penetration Testing Skills: DOM-
based XSS
DOM-based and Reflected XSS attacks are
delivered from the intruder similarly but have II. IMPLEMENTATION
important distinctions between them. DOM-based A. Web Application
XSS allows an attacker to structurally change an To demonstrate the Cross-Site Scripting
HTML page on the client side without being attack, we used a web application created using
detected by the server [6]. The web server responds
Python Flask, HTML, and CSS for our website
legitimately in this scenario and the malicious code
template, and created a virtual environment that
is only detected and processed by the client [6]. The
network and server environment may not be capable allows us to dependencies required by other projects
of detecting this client-side activity; thus, most separate. We utilize JavaScript for XSS payloads,
intrusion controls implemented at this level are although XSS is possible with other scripting
ineffective. The keyword in this attack is local since languages.
the unauthorized code is never sent to the server;
instead, the malicious portion of the script is
processed by the client’s browser. “An increasing
number of HTML pages are generated by
downloading JavaScript on the client side and using
configuration parameters to adjust what the user
sees, rather than being sent by the server as they
should be shown [6]”. DOM-based XSS takes
advantage of these user-supplied inputs [6]. For
example, content after the hash (#) symbol in the
Figure 6: Created virtual environment FL_Venv and listing its
following URL is only interpreted by the client's resources
browser [6].
The web application has the ability to
demonstrate reflected XSS in the top field and
Figure 4: Improving Your Penetration Testing Skills: URL
Stored XSS in the bottom comment field. The
misuse with hash (#) symbol
comments are stored in a database file.
 Figure 10: <script>alert(document.cookie)</script>

Lastly, we demonstrate a stored XSS payload that

Figure 7: Python Flask Web Application used for redirects website visitors to a new website. The
demonstrating XSS string is as follows:

B. XSS Payloads <script>

To demonstrate Cross-Site Scripting on our window.location='https://www.google.com';
website we tested three different payloads. The first </script>
was <script>alert('attack was executed')</script>
submitting this comment creates a pop-up window After the window.location an attacker can place any
URL including a cloned website controlled by the
that displays the message the attack was executed.
attacker that could be used for phishing or installing
A real attacker would never notify the victim that
malware.
they are being attacked, but this alert message
allows us to easily confirm the script was executed. C. Source Code
If the user input field was properly sanitized, this
script would only be posted as a comment text and
not load an alert message.

Figure 8: <script>alert('attack was executed') >

We also demonstrate this payload as a

reflected attack. This adds the string to the end of
the URL. Since the potential victim would already
trust this domain, it makes for a more effective
phishing attack.

Figure 9: Running as a reflected XSS

The next payload that we tested was also an

alert message that displays the contents of the
document.cookie line 46 in template.html that we
set. This is significant because many web
applications also contain Session ID information in
the cookie which can be used by the attacker to
login as the victim. Cookies are used by the web
server and browser to exchange network state
information [16]. Figure 11: HTML Template for website
 IV. CONCLUSION
Web developers should be knowledgeable
about XSS attacks and implement protections such
as security headers, filtering, and escaping. Filtering
Figure 12:HTML template for website and setting cookie
searches for known high-risk special characters and
language, such as <script> tags, JavaScript
commands, and other unwanted markups, and sets
them to a friendly value (encoding) [13]. Escaping
can be used to prefix the unauthorized input with a
backslash to ensure the unwanted code is not
executed [5]. In our HTML template, we have auto
escape set to false to keep the website vulnerable.
Security headers such as content security policy or
x-XSS-protection give developers control by
specifying resource policies, such as location,
protocol, and host policies, for their application
[14], Flags, such as HttpOnly, can be configured on
the server-side to prevent an attacker from
Figure 13: app.py
accessing sensitive cookie information on a client
device [5]. Resilient web applications treat every
source, including users and services, with zero trust
and assume each input (i.e., form, URL, or API) is
potentially volatile until proven otherwise [5].
REFERENCES

[1] https://informcontentclub.com/qa/why-do-most-
websites-use-javascript.html
[2] https://blog.hubspot.com/website/cross-site-
scripting
[3] https://www.kali.org/tools/xsser/
[4] https://owasp.org/www-community/attacks/xss/
[5] https://www.skillsoft.com/course/a8-and-a3-
cross-site-attacks
Figure 14: db.py [6] Gilberto Najera-Gutierrez, et al. Improving Your
Penetration Testing Skills: Strengthen Your
III. EVALUATION Defense Against Web Attacks with Kali Linux and
In our project proposal, we aimed to create a Metasploit. Packt Publishing, 2019.
website using HTML with a form view for [7]
simulating a stored cross-site scripting attack. In our https://www.youtube.com/watch?v=ABwS2MIxFP
project, we not only demonstrated a stored XSS Q
attack but a reflected attack as well. We decided to [8]
utilize Python Flask which we did not initially plan https://www.youtube.com/watch?v=yJSnggHSH1U
in the project proposal until further research. [9] https://learning.oreilly.com/videos/web-
security-common/9781788835077/
[10] Antani, V. (2016). Mastering javascript:
Explore and master modern Javascript techniques in
order to build large-scale web applications. Packt
Publishing.
[11] Associates), G. D. (gosselin &. (2014).
Javascript - the web warrior series. Cengage
Learning, Inc.
[12] Mamta03. "United States: W3C Issues New
Draft for XMLHttpRequest Specifications."
TendersInfo (Mumbai, India), sec. NEWS, 28 Aug.
2009. NewsBank: America's News Magazines,
infoweb.newsbank.com/apps/news/document-
view?p=AMNP&docref=news/12A60A7D81136B
D0.
[13]
https://www.acunetix.com/blog/articles/preventing-
xss-attacks/
[14] https://developer.mozilla.org/en-
US/docs/Web/HTTP/CSP
[15] https://www.trustedsec.com/blog/tricks-for-
weaponizing-xss/
[16] Ayala, L. (2016). Cybersecurity lexicon.
Apress.