Does an insecure website compromise the security of a payment system in an iframe?

Here’s a conundrum for you: would you trust this page with your credit card?

It has HTTPS and it has a GoDaddy logo with a padlock (if the significance of this is lost on you, my thoughts on both GoDaddy and padlock icons are well documented), so from a casual glance, it’s ok, right? But what if the SSL implementation looked like this:

Everyone remembers the problem with SSL 3, right? But we’re also seeing SSL 2 supported. This sparked an interesting to-and-fro today which went like this:

You can read that thread in it’s entirety if you please, let’s just say it wouldn’t add much constructive value by reproducing it all here. This isn’t an uncommon discussion which is why I’ve thought it deserved a blog post, that is the assertion that the security proposition of the merchant’s site is inconsequential so long as the payment provider is in ship shape. Now that the argument is established, let’s delve into it.

Two points of view

There are two points being made here that are worthy of discussion:

1. The original assertion that the site is handling payments insecurely by virtue of the observations above (there were other problematic security practices called out as well, but I’ll keep the focus on the transport layer for the sake of simplicity)
2. Countering that position is the argument that the payment facility is “fully secure” because PayPal’s iframe passes all the necessary compliance requirements

Let’s start with the compliance piece because at least we can tackle this with some objectivity. We’ll begin with the PCI DSS E-commerce Guidelines and in particular, the section on Secure Sockets Layer/Transport Layer Security (SSL/TLS) Encryption:

PCI DSS Scoping Guidance: PCI DSS Requirement 4.1 includes specific requirements for SSL/TLS implementations. SSL relies on the validity of the certificate and must be configured securely to meet strong cryptography requirements. Note that SSL v2 is no longer considered to be secure and must not be used for e-commerce transactions. If merchants worry that some consumers without the latest browsers will not be able to access the merchant’s site if the merchant upgrades to SSL v3.0, a consumer-education program should be considered that advises consumers how to easily upgrade their web browsers and which may also describe the security benefits of using a current browser to properly protect their payment card data.

Now keep in mind that this doc is from Jan 2013 so firstly, SSL 2 has been a no-no for a long time and secondly, we definitely know that SSL 3 is out in the wake of last month’s POODLE problems. But is the payment facility actually using insecure SSL versions? Let’s check the iframe info of the embedded PayPal form:

The content is loaded from securepayments.paypal.com and as it turns out, they rate quite well when it comes to their transport layer security:

So it’s all good then, right? Bad SSL versions banished, PayPal’s security awesomeness inherited on the parent site by some kind of cyber-osmosis and PCI well and truly satisfied, right? Well this is where it’s a bit hazy and it begs the question – does the security profile of a payment system embedded in an iframe mean that the parent site can be insecure?

To be fair, security is all about degrees and there are worse implementations out there than just a weak use of SSL, for example not even attempting to implement transport layer security and simply embedding the form in a page served over plain old HTTP. This is not intended to be a discussion about the specifics of the Semi Precious Beads site per se, rather about the assertion that Nicola is making.

We’ll look at this in three ways: PCI’s view, PayPal’s view and a more holistic, real world view.

PCI’s view

In terms of PCI, there’s a nice little FAQ titled Ten Common Myths of PCI DSS which says this:

Myth 2 – Outsourcing card processing makes us compliant
Outsourcing simplifies payment card processing but does not provide automatic compliance. Don’t forget to address policies and procedures for cardholder transactions and data processing. Your business must protect cardholder data when you receive it, and process charge backs and refunds. You must also ensure that providers’ applications and card payment terminals comply with respective PCI standards and do not store sensitive cardholder data. You should request a certificate of compliance annually from providers.

Whilst this doesn’t explicitly say “Hey, don’t whack otherwise secure payment forms into websites with security issues”, it does dispel the myth that by merely using a compliant third party you’re good to go. But now, as of earlier this year, we also have PCI DSS 3 to deal with which makes things kind of interesting. There’s a great piece on pcicomplianceguide.org that spells out what this means and highlights some of the problems the revised standard is designed to deal with:

If a merchant’s e-commerce site redirects customers in any way to a third party for payment processing and the merchant’s site is compromised, the link or iframe could be redirected to a bad guy to collect payment information. It therefore makes sense that these e-commerce merchants should go through a much more rigorous SAQ/scan process.

Which is really the crux of the issue here – regardless of how good a job PayPal has done, if the site you do your shopping on is compromised (say because it uses weak versions of SSL), the customer still gets pwned and understandably, a little upset at the merchant. That article goes on to lament some of the vagaries of the new standard in terms of what it means to be “compliant”, but it’s also very direct when describing the real world risks:

This is a meaningful change of position because the Council is saying that SOME types of redirection are OK, but most security experts will tell you that ANY redirection is risky. Forensics auditors have indicated that there are plenty of real-world examples where both simple URL redirects and iframe redirects have been hijacked, sending customers to false payment pages where their credit card data is then stolen.

Amid all this we have to remember that PCI, as important as it is for merchants, is often heavily criticised for being little more than a series of checkboxes to tick. There are many instances of PCI compliant implementations being hacked and the ambiguity of positions like that described above do it no favours. Even still, it looks like the practice we’re talking about here may well fall foul of their latest standards.

PayPal’s view

The position of the payment provider is an interesting one and it’s not just PayPal, Stripe is another provider I’ve regularly seen this issue come up with. These guys want to get their services used as broadly as possible and inevitably they want the barrier to entry to be low. But they also don’t want to see their customers getting pwned so they need to try and find a balance somewhere. So what does this mean for the security position of websites embedding their payment form?

There’s a good discussion on the PayPal forum about this and the following observation is made:

I ask this only because in theory it is possible to host a website on a relatively unsecure SHARED server while linking (via the secure token methods) using a product such as PayFlow Link (which actually sits on the Paypal server).

PayPal responds with this (emphasis mine):

Think of it this way, if the Steve's soccer balls server is not secure, is it possible for an attacker to intercept the sensitive information as it's being collected in the browser but just before it's being transmitted to PayPal?  With PayPal Payments Advanced (Payflow Link), the form is hosted and secured by PayPal but it's still embedded on the merchant's website.  There's lower risk compared to solutions where all the payment information is being collected directly on your website but we still have to make sure the store website itself is secure.

Which, of course, makes perfect sense. Keep in mind if reading through the remaining posts on that forum that this is a pre-PCI DSS 3 discussion which may well change some of the views expressed there, but certainly PayPal’s quote above is still very relevant. But regardless of official statements or formal guidelines, the mechanics of how this sort of service works remains the same and certainly the payment form can be put at risk by the security profile of the parent site. Let’s delve into that further.

The real world view

Let me illustrate what we’re talking about here:

The point is that the merchant is in full control of what goes into that iframe. When everything goes to plan, it’s the payment provider’s form. If not, well… it could be anything. From an end user perspective all they know is what they see in the address bar and on the page and the problem is that those two attributes are usually indistinguishable when things work perfectly from when they’ve gone to hell. What they can’t see in the latter is that it’s no longer the payment provider’s form, rather it’s an attacker’s.

So how does this happen? How does an attacker get their form in there instead of the payment providers? There are many options here including simply modifying the parent page at rest (perhaps there were weak FTP credentials on the site), exploiting a SQL injection risk (it may be a data-driven page with content from a CMS) or using an XSS vulnerability to rewrite the iframe source, among others. These aren’t (usually) caused by dodgy SSL, but it illustrates that the security position of that merchant site can have a fundamental impact on what goes into that iframe.

Then there’s the risk of the transport layer itself. The merchant’s page is requested over a connection which could be compromised and the HTML markup – including the iframe tag – could be modified in transit. There are many, many precedents of this and indeed that’s why we have SSL / TLS in the first place. It’s also why PCI DSS is rather strict about it because they recognise the risk; that their requirement is for the payment form itself isn’t really the point, rather it’s an acknowledgement that there exists this thing known as a “man in the middle” attack and that traffic must be properly secured. It’s this simple: if transport layer security is important because there’s a concern about someone getting in the middle of the traffic, the concern should be equally shared across both the payment form and the page that embeds it because compromising either entirely breaks the security of the site.

Here’s another way of looking at it: when you click through to the payment form to checkout, there are 54 requests made. The first one is to the merchant with the weak SSL implementation and one of the last ones is to PayPal:

On what basis do you decide that the first request doesn’t matter as much and can therefore use SSL 2 or 3 but the second request – the one initiated by the first one – should be properly secured? It’s the same browser making these two requests over the same wireless network to the same access point then going through the same router using the same DNS then onto the same ISP through the same gateway. All these points are the ones most commonly compromised by a man in the middle yet we see very different attitudes to protecting the data. It’s entirely nonsensical.

Summary

PCI probably doesn’t like this practice very much but they’re a bit vague. PayPal believes you still need to take responsibility for the security position of the merchant site regardless of how well implemented their payment facilities are. The pragmatist looks at this more holistically and sees that the security position of the parent site is critical to the overall safety of the user experience.

None of this is particularly hard even though the guidance can be confusing. Going back to that original discussion between Paul and Nicola, it reads as though she’s received some bad advice from someone who has an inkling of some of the risks but wasn’t able to present the problem to her in the broader sense. Unfortunately the debate ensued on Twitter (something you really don’t want happening if you’re running an online business) and her views now stand on the public record.

PCI is a necessary thing and it’s something you want ticks in boxes on, no doubt. But don’t for one minute assume that those ticks make your overall service “secure” and certainly don’t assume “fully secure”. Customers care about the overall security position, not the semantics of compliance docs. It’s easy in this day and age to drop HTTPS over the entire site and disable insecure protocols so it should be a no-brainer – it’s something you just get done and put an immediate halt to this sort of debate.