What is an XSS Attack?
A cross-site scripting (XSS) attack injects malicious code into vulnerable web applications. XSS does not target the application directly. Instead, XSS targets the users of a web application.
A successful XSS attack can cause reputational damages and loss of customer trust, depending on the scope of the attack. Here are common examples:
- An XSS attack can employ a Trojan horse program to modify the content on a site, tricking users into providing sensitive information.
- Successful XSS attacks can reveal session cookies, which allow cybercriminals to impersonate real users and use their accounts.
In this article:
- Real-Life Examples of Cross-Site Scripting Attacks
- How Does a Cross-Site Scripting Attack Work?
- Impact of XSS Vulnerabilities
- XSS Attack Code Examples
- Detecting and Testing for XSS with Bright
Real-Life Examples of Cross-Site Scripting Attacks
British Airways
In 2018, British Airways was attacked by Magecart, a high-profile hacker group famous for credit card skimming attacks. The group exploited an XSS vulnerability in a JavaScript library called Feedify, which was used on the British Airway website.
Attackers modified the script to send customer data to a malicious server, which used a domain name similar to British Airways. The fake server had an SSL certificate, so users believed they were purchasing from a secure server. They succeeded in performing credit card skimming on 380,000 booking transactions before the breach was discovered.
Fortnite
In 2019, the popular multiplayer game experienced an XSS vulnerability that over 200 million users. A retired, unsecured page went unnoticed by Fortnite developers. The page had an XSS vulnerability that allowed attackers to gain unauthorized access to the data of all Fornite users.
Attackers could have used XSS, in combination with an insecure single sign on (SSO) vulnerability, to redirect users to a fake login page. This would allow them to steal virtual currency within the game, and record player conversations, as reconnaissance for future attacks. Check Point discovered the attack and notified Fortnite, but it is unknown if the vulnerability was exploited by attackers in the interim.
eBay
In late 2015 and early 2016, eBay had a severe XSS vulnerability. The website used a “url” parameter that redirected users to different pages on the platform, but the value of the parameter was not validated. This allowed attackers to inject malicious code into a page.
The vulnerability enabled attackers to gain full access to eBay seller accounts, sell products at a discount, and steal payment details. It was actively used by attackers to manipulate eBay listings of high value products such as vehicles. eBay eventually remediated the vulnerability, but follow-on attacks continued until 2017.
How Does a Cross-Site Scripting Attack Work?
Cross-site scripting is when an attacker manipulates a vulnerable website so it returns malicious scripts to the user. This process typically involves JavaScript, but an attacker can use any client-side language. XSS primarily targets JavaScript due to the language’s integration with many browsers.
The weaknesses that allow XSS attacks to occur are widespread. XSS attacks can exploit weaknesses in different programming environments – examples include Flash, VBScript, JavaScript, and ActiveX. The ability to exploit widely used platforms makes XSS attacks a severe threat.
Here are methods attackers use to compromise websites using XSS attack:
- Targeting website functions that accept user input—examples include login forms, search bars, and comment boxes. The attacker loads their malicious code on top of the valid website, deceiving the browser into running their malware whenever users load the site.
- Malicious code on another domain—according to how the attacker injects the code, malicious content may not be on the actual website. It can be a transient element that only looks like part of the site at the time of exploitation.
- Stealing session data—the JavaScript runs on the victim’s browser page, permitting the attacker to steal sensitive information about the user from the website session. The attacker can compromise the user’s session and gain unauthorized access.
Here are different ways to trigger an XSS attack:
- A user can trigger the execution automatically when they load the page or hover over certain page elements, including hyperlinks.
- Attackers can carry out XSS directly, for example, in an email message containing a malicious link.
- Certain XSS attacks don’t have a particular target. Rather the attacker exploits a vulnerability in a site or application targeting random victims.
Here are some ramifications of an XSS attack:
- Depending on the attack’s scale, attackers could compromise user accounts, activate Trojan horse programs, and modify page content, misleading users into sharing their sensitive data.
- Attackers could gain information about session cookies, so they can impersonate authentic users and compromise their private accounts.
An effective cross-site scripting attack may have consequences for an organization’s reputation and its relationship with its customers.Â
Learn more in our detailed guide to reflected xss.
Impact of XSS Vulnerabilities
The impact of an XSS vulnerability depends on the type of application. Here is how an XSS attack will affect three types of web applications:
- Static content—in a web application with static content, such as a news site with no login functionality, XSS will have minimal impact, because all users are anonymous and information is publicly available.
- Sensitive data—if an application stores sensitive user data, such as financial or health services, XSS can do major damage because it can allow attackers to compromise user accounts.
- Privileged users—if an attacker can use XSS to take over the session of a privileged user, such as the web application administrator, they can gain full control over the application and compromise all its data.
Related content: Read our guide to XSS vulnerabilities
XSS Attack Code Examples
Cross-site scripting vulnerabilities typically occur in parts of a website or web application where users can post or upload their own data—for example, the comments section of a blog.
The code in the following examples was provided by the OWASP project.
Reflected XSS Example
The following code segment reads the eid parameter from the HTTP request and displays it. There is no validation in the code to verify that that value of eid is alphanumeric text. An attacker can replace this value with malicious source code, and it will execute in the browser.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
The danger of this vulnerability is that attackers can email the URL with the malicious code to a user and cause them to click it, thus running malicious code on their own device.
Stored XSS Example
The following code is a database query that reads an employee’s name from the database and displays it. The vulnerability is that there is no validation on the value of the name data field. If data in this field can be provided by a user, an attacker can feed malicious code into the name field.
This malicious code will then be stored in the database, and whenever the name is displayed in a browser, the malicious code will execute.
<%… Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>
Employee Name: <%= name %>
Error Page XSS Attack Example
Consider a traditional 404 error page that displays the URL the user attempted to access and informs the user that it does not exist.
<html>
<body>
<? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?>
</body>
</html>
Because the code does not validate the REQUEST_URI, an attacker can manipulate this data value to execute a malicious script. Attackers can use this, for example, to hijack a session cookie.
http://testsite.test/<script>alert("TEST");</script> The result is: Not found: / (but with JavaScript code <script>alert("TEST");</script>)
Detecting and Testing for XSS with Bright
While Dynamic Application Security Testing (DAST) tools are able to test for some XSS vulnerabilities, they are often limited and produce a high ratio of false positives.
Bright can automatically crawl your applications to test for reflected, stored and DOM-based XSS vulnerabilities, giving you maximum coverage, seamlessly integrated across development pipelines.
Engineering and security teams can trust Bright’s results, with automatic validation of every XSS finding carried out, with no false positives. Bright even generates a screenshot proof of concept along with comprehensive developer friendly remediation advice to fix the issue quickly and early.
Get a free Bright account and start testing today!
