Could a Single XSS Attack Empty Your Wallet Without You Knowing?

Wait, what’s XSS code? If it hasn’t crossed your radar, it should.  

On a busy day in 2018, thousands of people handed over their credit card details to British Airways, the UK’s largest airline, trusting their data was safe. But in the shadows, Magecart hackers were harvesting their card numbers.  

Magecart isn’t just a name; it’s a collective of hacker groups specializing in injection attacks like XSS. This type of attack injects malicious code into trusted websites to skim payment card details and personal data.  

Researchers have identified at least six groups linked to Magecart, with Group 6 the culprit behind the British Airways attack. So, whether you’re shopping online or running a business, it’s smart to ask: Could you be their next target? 

What does XSS stand for?

First, let’s start with definitions: XSS stands for cross-site scripting. 

Now, you may wonder why it’s “XSS” rather than “CSS.”  

Originally, cross-site scripting occurred when attackers used JavaScript on their website to read private data from another. They did this by loading their site into a hidden frame (iframe). Then, Netscape introduced the Same Origin Policy (SOP), which prevents websites from doing this unless the URLs of both sites had the same origin. 

A site’s origin involves three (3) elements: its domain (like www.lastpass.com), port number (like Port 80 for http), and protocol (http or https). If any of those differ, the browser treats the iframe as off-limits.  

So, even if the iframe loads sensitive data (like your bank info), the malicious JavaScript can’t read it. 

As time progressed, the security community pivoted to “XSS” to avoid confusion with Cascading Style Sheets (CSS). This is why cross-site scripting is known as XSS today.  

What are XSS attacks?

In a nutshell, an XSS attack occurs when an attacker injects malicious JavaScript into content you see on a site.  

These scripts are executed in your browser because the site didn’t properly validate or encode user input (specifically the input submitted by the attacker). 

Essentially, XSS allows attackers to bypass the Same Origin Policy (SOP) by exploiting the lack of proper validation or encoding to deliver attacker-controlled code.  

Because your browser views this code as coming from a trusted “origin,” the attacker’s script executes with full privileges when you load the compromised page.  

This allows the attacker to steal your session cookies, capture your keystrokes as you type in your login credentials, redirect you to a phishing site, or even impersonate you. 

And that’s not all: Attackers have two more tricks up their sleeves to bypass SOP.  

The first manipulates the DOM (Document Object Model) of a web page inside your browser, while the second hijacks your browser’s trust, so it acts on their behalf. 

These two techniques are called DOM-based XSS and CSRF (cross site request forgery), which we explore below. 

What is the difference between XSS and CSRF?

As mentioned, cross-site scripting (XSS) is where attackers inject malicious JavaScript code into web pages you visit. This script runs in your browser and can steal your information or manipulate the content you see. It's a client-side attack. 

Meanwhile, cross-site request forgery (CSRF) tricks you into sending unwanted requests to a website on behalf of the attacker.  

In a CSRF attack, the scammer doesn’t steal your session cookies. Instead, they send you a forged request embedded in an email link that looks like it came from your bank. Often, the forged request is for a money transfer. 

If you’re already logged in to your bank and click on that link, your browser will attach your active session cookie to the forged request.  

Your bank will then receive the request and think it’s you making the transfer because your session cookie is attached.  

In simpler terms: 

• XSS tricks your browser into running malicious code that steals your data. 

• CSRF tricks your browser into performing unauthorized actions on a website where you’re already authenticated. 

What are the types of XSS attacks?

XSS has been around for decades. Today, security experts classify XSS into two main types: server XSS and client XSS.  

But many acknowledge that, historically, XSS was categorized into three (3) main types.  

Below, we uncover why DOM-based XSS is the one most likely to bypass your defenses. 

1. Stored XSS (persistent XSS): Here, malicious code is permanently stored on a target server and served to browsers whenever content is viewed. Magecart’s credit card attack is a classic example of this type of attack. 
2. Reflected XXS (non-persistent XSS): Malicious script is reflected off a web server, such as in error messages or a search term. Here’s how it works: The attacker replaces the search term in an URL with their own JavaScript code.  Next, they send the link to you via email. When you click that link, the malicious code gets reflected by the website’s server back to your browser, which executes it, thinking it’s safe content from the site. 
3. DOM-based XSS: The vulnerability exists in client-side code, where the attack manipulates the DOM (Document Object Model) environment in your browser. 

But what’s a DOM? Essentially, it’s a map your browser constantly updates to give you an interactive experience on a website. The DOM is a live representation of a webpage your browser creates from HTML (the page’s original source code). 

This map or live representation allows scripts (like JavaScript) to change, add, or move elements, allowing pages to be interactive and responsive without reloading. 

So, when you see messages pop up, layouts change, menus expand, or live data updated on a webpage, it’s the DOM at work.  

In a DOM-based XSS, attackers manipulate the DOM to execute malicious JavaScript in your browser. It’s a client-side attack, which is different from a reflected XSS, where the server sends the malicious code directly.  

This brings us to the recent clickjacking attacks, which some have equated with DOM-based XSS. While the attacks sound similar, they differ in how they enable credential theft: 

• DOM-based XSS manipulates the DOM to inject malicious JavaScript code into a target webpage. The injected payload can send you to a phishing page or fake application login page, where your credentials are stolen when you enter them. 

• In clickjacking, the attacker overlays an invisible form and invisible buttons on a page you visit. The form and buttons are invisible to you because the opacity has been set to zero. When you interact with the visible parts of the page, your clicks perform hidden actions.  

For example, you see a “View Content” button and click it, but this action triggers clicking the invisible “Submit” button underneath (which you can’t see). Essentially, clickjacking tricks you into interacting with invisible elements controlled by the attacker. It's worth noting, however, that DOM XSS can be combined with clickjacking in a chained attack. 

 

If your password manager detects the invisible form as legitimate and autofills your credentials, those credentials can be sent to the attacker’s server.  

 

BUT if you’re a LastPass customer, you’re protected: 

1. By default, LastPass displays a confirmation prompt before autofilling your personal info (like addresses or banking details) within a webform.  
2. You can also set additional security measures for autofill.  
3. Your password will never be autofilled where the URL isn’t an exact match for the URL in your vault. 
4. Most importantly, the new 4.146.8 LastPass browser extension addresses the “zero opacity” threat for these browsers: Chrome, Edge, Firefox, Opera, and Safari. 

Now that you’ve seen how attackers can leverage the different types of XSS attacks to hijack sessions and steal credentials, let’s look at how these attacks play out in the real world. 

What is an example of an XSS attack?

British Airways, 2018 

The Magecart attack on British Airways was one of the biggest high-profile XSS attacks in the world, where attackers injected 22 lines of malicious JavaScript code into the British Airways checkout page. 

The script skimmed credit card details from 380,000+ booking transactions during the peak travel season between August 21 and September 5, 2018. The compromised data included card expiration dates and CVV codes, the three-digit numbers that authenticate a card. 

Here’s what the attackers did: 

• First, they identified a vulnerable web component (specifically a third-party JavaScript library) on the British Airways baggage claim information page. The page was last updated by British Airways in December 2012. 

• They then revised the component to include 22 lines of malicious JavaScript code. 

• When customers entered information into the payment form, the code grabbed everything they typed in. 

• After customers hit “Submit,” the stolen data was sent to an attacker-controlled server. And here’s the chilling part: The server used a domain name similar to British Airways, and it had a valid SSL certificate (which the attackers paid for).  

So, what customers saw was the familiar padlock icon, which led them to believe their data was protected in transit. But behind the scenes, the attackers were actually harvesting their card payment details. Essentially, 22 lines of code was all it took to skim payment info from thousands of customers. 

 

The British Airways attack went undetected for several months, exposing customers to financial risk even as they interacted with a trusted brand. This brings us to an important question. 

What are some ways to detect XSS vulnerabilities on websites?

If just 22 lines of code can put your data at risk, how can you ever feel safe online? 

The answer is, detecting XSS is a proactive process. Here's what you need to know. 

Who	What you can do	Why it matters
Businesses	Use automated scanners like Burp Suite, OWASP ZAP, and ZeroThreat	DAST (Dynamic Application Security Testing) tools like OWASP ZAP identifies vulnerabilities in a running environment so DevOps teams know what needs fixing ZeroThreat, another DAST tool, detects DOM-based attacks in JavaScript-heavy frameworks like React, Angular, or Vue
	Manually test input fields with safe scripts	Allows security testers to use custom safe payloads to uncover weaknesses in how input is handled on the website Complements automated scanning
	Follow OWASP’s reflected XSS testing guide	Detects non-persistent XSS by injecting test payloads and analyzing responses
	Audit third-party scripts regularly	Attackers often manipulate compromised external code to execute XSS attacks
Consumers	Watch for strange behavior like pop-ups, redirects, or odd login forms	These can be signs the site has been hijacked
	Use script-blocking browser extensions like uBlock Origin or NoScript	Blocks suspicious scripts from running in your browser
	Avoid clicking on unknown links or entering sensitive info on unfamiliar pages	Puts your data at risk of being harvested by scammers
	Keep browsers and extensions updated	Patches often fix known security vulnerabilities
	Report suspicious site behavior to the brand you’re doing business with	Alerts the brand to issues so they can take steps to protect your data

 

What is the most effective defense for XSS?

Whether you’re a consumer or business, the best defense for XSS involves a defense-in-depth approach that includes these security controls. 

Defense mechanism	Description	For consumers	For businesses
Input validation & sanitization	Automatically rejects improperly formatted user input	Keep browsers updated to benefit from security enhancements against XSS	Use modern web frameworks like React and Vue, which come with built-in sanitization Combine with DAST tools like ZeroThreat to detect DOM manipulations
Content Security Policy (CSP)	Browser response header restricts which scripts can run on a site, blocking inline JavaScript or those from untrusted domains	Keep browsers updated to benefit from CSP enforcement	Implement strict CSP browser headers to disable unsafe inline JavaScript and only allow scripts from trusted sources
Output encoding	Converts characters that can be interpreted as code into safe, encoded versions before displaying on web pages	Not applicable for consumers directly	Implement encoding to ensure everything users type is treated as plain text and not code to be executed on the site
HttpOnly Cookie flag	Prevents JavaScript from accessing sensitive cookies	Modern browsers enforce cookie security flags so be sure to keep your browser updated to benefit from this protection	Set HttpOnly flag to make the cookie inaccessible to client-side JavaScript
Web application firewalls (WAF)	Monitors and blocks malicious traffic patterns	Not applicable for consumers directly	Deploy WAFs to block URLs containing known harmful scripts from being reflected to users
User awareness & training	Aids in understanding XSS tactics	Avoid untrusted sites and links	Train employees on phishing awareness and safe browsing habits
Trusted, award-winning password manager like LastPass	Securely store and autofill credentials only on trusted domains	Password autofill only on verified sites   Confirmation before autofilling personal info on webforms   Additional security controls for autofill	Makes regular extension updates for your security Employs world-class organizations to conduct audits of LastPass services and infrastructure Gives you direct access to the LastPass security team to report potential vulnerabilities and attacks. Respects your right to transparency by giving you access to LastPass certifications and security documentation

 

I can rely on LastPass to provide autofill and password keys quickly and safely (Verified G2 user in broadcast media industry).

LastPass solves the challenge of managing and remembering multiple passwords by securely storing and autofilling login details across devices, saving time and effort. It also generates strong, unique passwords, which provides peace of mind that our accounts are better protected. At work, we use LastPass to give each user their own secure access. We can easily turn on or off access as needed, which helps keep our systems secure and well-managed (Verified G2 user in small business).

It securely stores my passwords for the sites I visit. I love that it can autofill the username and password when I visit a site. Additionally, I like that it generates strong passwords for me. It can also store passkeys and other sensitive information, such as credit cards and social security numbers. The app is very easy to use (Verified G2 user in web development).

Get LastPass free today for effortless security and greater peace of mind (no credit card required). 

Type of account	Who it’s for	Free trial?
Premium	For personal use across devices	Yes, get it here
Families	For parents, kids, roommates, friends, and whoever else you call family (6 Premium accounts)	Yes, get it here
Teams	For your small business or startup	Yes, get it here
Business	For small or medium-sized businesses	Yes, get it here
Business Max	Advanced protection and secure access for any business	Yes, get it here