Cross-Site Scripting (XSS) Can Steal Payment Info From Payment Processors
Want to how cross-site scripting can steal payment information? Check out this post where we look at payment processors, XSS, and its impact on app security.
Join the DZone community and get the full member experience.Join For Free
Just because your Payment Processor has PCI Level 1, doesn't mean you can ignore Cross-Site Scripting. If you handle money, you process credit cards. (It’s pretty hard to email cash.) To prevent fraud, the card industry has created the PCI data security standard (DSS). Processing cards? Follow the specific guidance in PCI and you’ll be safe, right?
Recent events have shown that payments have been subject to sustained attack, demonstrating that PCI DSS compliance is a necessary component, but it is not adequate protection when taken in isolation.
In fact, the card industry has gone beyond the technology of the PCI DSS and has defined PCI compliance levels, (here are Visa’s definitions) ranging from level 1, the highest volume processors, to level 4, the lowest volume. Higher volume processors have more stringent requirements because they are a more attractive target and, therefore, higher risk.
Modern web design is like car manufacturing. Just as car manufacturers depend on suppliers for components and even whole sub-assemblies, so do web application developers. Relying on subcontractors for expertise helps reduce risk. Why learn the intricacies of developing ignition systems when you can buy one from Bosch? Similarly, why learn the details of protecting payments when you can rely on a service to do so?
Payment Processors Make PCI Compliance Easy, but not Security
In fact, one of the reasons to use a payment processing service is that your PCI compliance becomes much easier, in effect, saying “hey, I use this PCI level 1 service, so I’m relying on them to do most of the heavy security lifting.” For example, Stripe has an extensive PCI section in their documentation. Generally speaking, a payment processing service will make it easy for you because all their documentation is readily available. (If it’s not, you should probably consider it a bad sign.)
So far, so good. You can use a service to make PCI compliance easier. Yay, outsourcing! Letting organizations focus on what they’re good at is less distracting and more efficient. How could this possibly go wrong?
Most of the PCI DSS was written with the assumption that you’d have almost all of the code for your application under your control, and it’s still getting used to the idea that meeting PCI DSS requirements now requires cooperation among several companies. Letting Stripe handle your payments is an important component of your overall security, but the story doesn’t end there.
Protecting Payment Card Data From XSS
Where relying completely on your payment processor goes awry is that as the developer, you are still responsible for interactions between app components. Yes, the payment processing pages or frames will be well-defended, but anything else that is part of your web application can read the contents of the payment frame. Want to have a chat window? Well, if you don’t write your own, the scripts that run the chat window can read payment details. That makes any web application component into a possible attack vector, but very few non-payment-related components will have recognized the need to implement a PCI-style deep security program.
To continue with our automotive metaphor, we just started working with the application component that is the equivalent of a Takata airbag. It’s part of our application, so we’re responsible for making sure it’s secure. But it’s not our code, and in fact, can interact with our code in ways we don’t understand.
So, what can we do? Browser scripts and multiple sources of content is a classic cross-site scripting (XSS) setup: two pieces of code come together in the user’s browser and interact in a way where that exposes data. If an attacker can get a rogue script to run next to your payment processing page, they can read anything they want. The only ways to stop it are to prevent the script from loading or to prevent the script from sending any compromised data.
The first option isn’t really an option. We’re likely using the script because it does something faster, better, and cheaper than we are able to. (Would Ticketmaster have written their own chat client? I doubt they could have done it anywhere near as cost-effectively as embedding an existing client in their app.) Insisting that we control every line of code in our own application is no longer viable. So, we have to turn our attention to preventing the attack from working.
Protect Your Customers Visiting Your Website or Application From XSS
The best way to stop XSS attacks from having an effect while maintaining the freedom to use all of the best available web components is to prevent a rogue script from communicating results. Web standards give us the tool for this: HTTP’s Content Security Policy (CSP). CSP is like an application-level firewall. Developers can instruct the browser to only permit communications to a set of allowed sites. The application tries to connect to your site for data? Allowed. It needs to communicate with a chat provider? Allowed. An attacker wants to send stolen data to their server? Blocked!
As web application architecture has become increasingly atomized, the role of the application developer has become one of design and assembly, while leaving much of the heavy lifting to platform companies. Ensuring application security when application code is distributed across multiple code bases (or even companies) requires different security tools and approaches than when all code is developed in-house. CSP is an important new addition to the security toolbox, especially because it prevents attacks that occur in an end user’s browser where control has typically been very limited.
Published at DZone with permission of Matthew Gast. See the original article here.
Opinions expressed by DZone contributors are their own.