Monday, 16 November 2015

https and shopping, for dummies

When you are using any on-line shop you are expected to hand over some personal details, including a credit card number, name, address, expiry date, code from back of card, etc.

Indeed, these are the very details that a hacker would like to use to buy things using your card. They have to be, as you are in fact buying something using your card!

One the the great things that computers can do is send that data to the merchants securely so that nobody can snoop on it on the way (not even Theresa May). This is important because your Internet traffic will go via a load of different companies to get to the end point, and you cannot be sure of trusting every individual within those companies who could have access to your data to not to be a criminal. This is even more important when not at home and using someone's wifi.

Look for the padlock
You can tell when this is happening by a padlock by the web address. This is the browser telling you it is secure, and that the other end at least matches the web address. If you click on the padlock you can get more information, and in some cases the browser will show you the legal name of the company by the padlock. What this means is that a protocol called "https" is being used.

But there are two key parts to using https  - one is the way the data is sent so that nobody can snoop on it, but the other is checking the other end is who they say they are.

This second part is very important, as the other end, the web server, does get to see all of those details you are entering. If they are not really the merchant of bank or payment company that you think you are talking to, but instead some hacker, then the padlock does not help you.

To ensure that credit card details are handled carefully, there is a whole heap of crap that retailers have to go through called PCI/DSS. It is well intentioned, but really is horrid from a technical point of view. I don't mean that it forces unnecessary levels of protection and security - most of the ideas are sensible - I mean it makes huge assumptions about the way things are done and then asks lots of technically stupid and leading questions that can be impossible to answer honestly.

However, in spite of all of this annoyance, it seems that the basic level of PCI/DSS compliance, the self assessment questionnaires, lacks a simple question about your web site...

Yes, they do require that card details are encrypted when sent, but they don't require that the previous web page - the page where you type in those details - is secure (using https).

I'll try and explain - when you are presented with a form to fill in, that form has come from a web server. When you type in those details and press the button, those details are sent to a web server, and a reply page comes back. They do not have to be the same site or use the same protocol. It is quite possible for the form asking for details to be insecure (just using http, and no padlock), but the details you send are sent using https, so secure. So yes, the details are safe from passive snooping on the Internet. Apparently this meets the PCI/DSS self assessment questionnaire and requirements.

But there are two major issues with this:
  1. It trains the public that they do not have to expect the padlock when completing the details. This is very bad. It is a bit technical for someone to check if the details will be sent securely or not, and you cannot expect everyone to be that technical. It is only by the public being aware and checking at the very least that there is a padlock that hackers can be thwarted and preventing from defrauding banks.
  2. It allows various types of attack that would not be possible if the form itself was secure (example below).
The attack I am talking about relates to knowing the other end is who they say their are. There are various ways to attack the bits in the middle of the Internet and even divert them (DNS attacks, DSL router attacks, ARP/ND spoofing, routing/BGP attacks, and so on). These could send the request for the web page to a hackers server instead of the merchants real web server.

Now, if https is used, the hacker cannot pretend to be the merchant or server in questions as they do not have the keys that are necessary to make the padlock appear. The browser would tell you that something is wrong.

However, if the form is just a normal, non-secure, web page, they can send an identical looking form to you. When you post the details, instead of those going securely to the merchant or the bank, they go to the hacker.

Now the hacker can even be clever, and after copying the details he can send your web browser on to the right place, a secure https web site for the bank or merchant with your details, so to you it looks the same. Indeed, he could be feeding the order to the merchant cleanly as well and allow your purchase to work perfectly with neither you, nor the merchant, knowing there is any hacking. Then, when he has lots of card details, he can use all of those card details, or sell them.

This is why it is very important to check the page you are filling in has the padlock - at least do that. There are many more checks you can do, but the most important is that simple first step.

Sadly I found a merchant that is using something called an iframe. It means you have someone else's web site in the seamlessly shown middle of your web page. In this case they have the payment company's web site in theirs, but you do not see an address bar and do not see a padlock.

So in this case you cannot tell that the data will be sent securely. You cannot tell who it is being sent to. You cannot tell the encompassing page has not been changed so that it includes some hackers page in the iframe. You promote a public acceptance of payment pages that do not show the padlock. It should not be allowed, and I hope the PCI/DSS rules are changed to stop it.

Sadly their card processing provider, Sage Pay, seem a little disinterested in this issue and even referred me to examples in their documentation where they say the padlock won't show, as if that was acceptable!


  1. Naming and shaming does tend to work in general, you just need to do it (as you are doing now) publicly. I'd suggest tweeting this to @troyhunt as he seems to have a reasonable amount of support in the security space - and spring to mind!

  2. I think PCI ASV scanning should be compulsory for all websites which take credit card payments or redirect to payment providers which do. You can get quarterly scans for less than £50/year and it should pick up on things like this and make then an automatic failure.

    1. Adding to my previous comment it is a Mastercard requirement that websites which even only redirect to the likes of sagepay must have a PCI ASV pass.
      That is probably something which is overlooked by most companies as PCI do not make and comment about it.

  3. I think you missed an important point, which is to not blindly trust the padlock. SSL certificates can be obtained pretty cheaply now (or even for free?) and some authorities don't go very far to check whether the given details are valid so even if you click the padlock, it may still look somewhat legit. Sometimes even the real sites have legal names that may be entirely unfamiliar.

    It is therefore important to check the domain name but this has its own pitfalls. IDN homograph attacks are nasty, though browsers have taken measures to address this. It doesn't help that, much like the legal name issue, some sites often redirect to entirely different domains to take payment. On a rare occasion where I was presented a Verified by Visa page that wasn't in an iframe, I was shocked to discover that it does not use Visa's own domain but some obscure domain I had never heard of. I really cannot fathom how a company the size of Visa cannot make it work with their own domain.

    In short, web security sucks.

    1. I have not really missed the point - as I say, there are other checks to do - I am saying that for the non technical person *AT LEAST* please check the padlock. If people don't even do that, then you don't need to get clever with IDN homographs to fool people.

  4. Even if there is a padlock it gives no guarantee that iframed content isn't being MiTMed. The 3D secure system has been training people to accept iframed payment forms blindly for years.

    Couple that with the fact that RBS boasts about their 'Advanced MD5 encryption' on their payment gateway and it's clear that the entire banking sector in the UK is clueless about security.

    1. No, not a guarantee, but a step the non-techie user can do, and am important one.

    2. Do they really? I had a quick glance at the certificate on their login page but it wasn't using MD5. Do you have a link or some other sort of evidence/proof?