Things you probably don't want to do on your [airline] website's payment pages

Web User Tracking and Privacy

The recent news coverage of how certain companies have used Facebook's graph APIs to hoard user data have [slightly] raised people's awareness of the lack of privacy online. This has led to some good and healthy discussions about online data collection vs user privacy. While it is not a new thing that companies use a wide variety of tools to gather as much data as possible about their users, many users have been blissfully unaware of the extent of how much they are tracked when they do anything online; whether shopping, making airline/hotel/car reservations, or just reading a news article.

While it is now established that many companies use a wide variety of tracking tools on their websites and in their mobile apps to gather more information about their customers and how they use these websites, the level of detail of how much data is gathered and how many people have access to that data may still be fuzzy at best to the average website user. Most of these trackers are third party tools from companies who are happy to gather and analyze huge amounts of user and user behavior data. The output visible to these tracking companies' customers (i.e. website owners) will often not show the detail and granularity of the data gathered and stored. While the tracking tools may collect a lot of very detailed data about website and app users, the "visible part" is often limited to colorful charts and reports showing aggregate data for a large number of users. Behind the scenes, it can be a lot more invasive with logging details down to including every mouse and keyboard input done by a website user.

User tracking and the detrimental effects it has on user privacy is an interesting topic, but on top of privacy concerns, the use of tracking tools can often introduce other unintended security issues that may violate industry regulations such as PCI-DSS and regional/local legal requirements like GDPR.

Airline IBEs and PCI-DSS

I recently had a quick look at a few well known airlines' internet booking engines. Like many others, airlines like to use online trackers to get a better understanding of how users use their websites, and where they can make changes and tweaks that will increase sales and boost revenue. This is very often done using third party tools where javascript and/or other resources are loaded from a third party controlled website/host. Very often, other third party hosted resources such as js frameworks hosted by CDNs are also used rather than locally hosted resources.

Setting the obvious privacy concerns aside, a more interesting aspect is when these third party hosted resources are used on payment and checkout pages: pages where e.g. credit/debit card data is processed. This of course introduce additional concerns regarding PCI-DSS compliance since all those third party scripts will have access to payment data entered on those pages, and unless the right precautions* are taken the same scripts can be modified by third parties at any time without alerting users or website administrators of the site that use those scripts to the fact that the code actually running in users browsers is no longer the same as the same code that was originally intended to be used.

* = SRI - Subresource Integrity can be used to preventing modified third party code from running in modern browsers. It is advisable to deploy together with a content security policy (CSP) which can define what sources should be trusted for different types of content along with a URL that modern browsers can automatically report policy violations to.

While end users may be unaware of e.g. PCI-DSS and other data protection requirements, I would expect that medium sized and large airlines would have technical staff who should be aware of the fact that a third party script loaded on a payment page will have access to any data present on, or entered, on that page. The same companies probably also have one or a few people involved in PCI compliance, and although PCI compliance is often handled by people with limited technical skills they should at a minimum be aware of the risks associated with dynamically loading third party code from third party resources. However, when looking at some airline websites' checkout/payment pages, I almost get the impression that even some of the most basic PCI-DSS compliance requirements have been set aside for the benefit of user tracking and data gathering performed using third party tools.

A second interesting aspect is that these sites often use EV / 'extended validation' certificates that make their company name show up in green in browser address bars. While this is intended to make it clear to users which company/entity they are interacting with and instill trust that they're interacting with the correct entity, the current implementation of EV certificate indicators in most web browsers don't make it clear to users when the same page include resources loaded from and controlled by third parties.

Some of the PCI-DSS requirements that appear to me as possibly overlooked by at least a few of these airline sites are:

• 2.2.5 - "Remove all unnecessary functionality, such as scripts...": In my opinion many of these third party scripts absolutely fall in the scope of 'unnecessary functionality' for a payment page. If the script is not directly needed for successful processing of those payments, it doesn't belong on a payment page.
• 3.2.2 - "Do not store the card verification code or value...": Those who have a generic key logger running on the credit card page would appear to be in violation of this requirement...
• 4.1 - "Use strong cryptography and security protocols": Many of these third party hosts support older insecure versions of TLS/SSL and/or insecure ciphers. Even if they don't directly transmit cardholder data, this can potentially be used by unauthorized third parties to manipulate script content while in transit.
• 6.3.2 - "Review custom code prior to release to production or customers" and 6.4 - "Follow change control processes...": How can you review code and follow change control procedures for code that is dynamically loaded by each end user system from third party controlled hosts? Without using SRI (which very few airlines do), there is no way to know when third party scripts/content has been modified or to block modified content from loading.
• 6.5.1 - "Address common coding vulnerabilities in software-development processes..." / "...injection flaws...": This practice is by definition code injection from third party controlled systems.
• 12.8 - "Maintain and implement policies and procedures to manage service providers": Does anyone at these companies even have an idea of how many third parties have direct or indirect access to their customers' payment data through inclusion of third party hosted scripts?

Examples

Without making this rant too long, I will just let a few screenshots talk for themselves.

The screenshots below are from the payment pages of a few well-known airlines, and on the right hand side of each one is the Chrome development tool window (which you can launch by pressing F12 while using Chrome) showing which scripts and other resources are loaded by the same page, and from which site/host it is loaded. I really wonder if all those third party sites are involved in the same airlines' PCI-DSS certification programme and audits, and if each of them are PCI compliant.

Alaska Airlines

Emirates

Etihad

Finnair

Is that a keylogger on your credit card form, Finnair, or are you just happy to see me?

What does PCI-DSS requirement 3.2.2 say about storing CVVs?

Frontier Airlines

Jetblue

Korean Air

Lufthansa

SAS

Silkair

...the list can go on and on, but I think that's enough examples of payment pages littered with excessive third party content.

None of the airlines above have a defined content security policy (CSP) to control which third party sites are valid sources for loading scripts and other content, and none of them use subresource integrity (SRI) to protect users from scripts that have been tampered with or otherwise modified while hosted on third party sites.

The next time you are going to pay for something online, press F12 to launch your web browser's developer tools, and you can see for yourself what third party resources are included in the payment page.

I will include just one more example, this time from an airline that has implemented their payment page in a more-clean-than-average way, with only a minimal set of scripts loaded from their own servers, Visa's servers, and from an Adobe server with a qatarairways.com hostname:

Qatar Airways

FAQ

What's the problem?

TL/DR: Some airline websites make excessive use of third party scripts/CSS/html hosted on third party sites/hosts not controlled by the website owner, which in turn make them exposed to potential vulnerabilities at those third party sites. In other words: they expose a larger than necessary attack surface. When this is done on payment pages, it increases the chance that they may leak their customers' credit card details to unauthorized third parties.

I'm responsible for an airline website that does this - what is the worst that could happen?

Someone: either an authorized rogue user at a third party organization, or an unauthorized person who have found a weakness or backdoor that can be used to make modifications to one of the third party hosted scripts (or CSS files) can modify one of the scripts in order to make it capture credit card data and funnel it elsewhere. When discovered, the credit card companies will invite you to pay stiff penalties for the breach if you want to continue processing credit card payments, and depending on where in the world you are located/based you may also be legally required to issue a breach notification. This will inevitably lead to negative publicity for your organization.

Has this ever caused a problem in the real world?

Yes, it has. Not too long ago, Delta had customer credit card data exposed by a third party script loaded on their site as part of a chat help tool:

• https://www.delta.com/content/www/en_US/response.html
• https://www.reuters.com/article/us-delta-air-cyber-24-7-ai/sears-holding-delta-air-hit-by-customer-data-breach-at-tech-firm-idUSKCN1HC089

What can I do as a site owner to limit the ways I expose user data to third parties?

1. Use common sense and limit the number of third party resources you load from third party sites/hosts to the minimum set needed.
2. Implement CSP to control which third party sites can be referenced from your site, and use SRI to block third party content from loading if it has been modified/tampered with.
3. Involve your internal or trusted external technical resources in compliance reviews. Don't just rely on checklists and scan tools for e.g. PCI compliance.
4. Make yourself aware of, and follow industry best practices to protect your (and your customers') data.
5. Use common sense. See #1.