QR codes are a highly convenient way to link a physical object to a URL. Point your phone’s camera at the 2D barcode and you’re instantly taken to a website.
That’s something which can have security consequences, as mobile guru Terence Eden explains.
Recently, Islington Council in London has partnered with Verrus to bring mobile phone payments to car parking.
It’s a really simple way to improve paying for parking – but it does leave open some fairly serious security risks.
The QR codes being used by Islington Council are fairly clearly displayed on the side of the parking meters – but there is no printed call to action.
Which raises the question – what does scanning the code do?
From a practical point of view, would anyone scanning the code know that it allowed them to pay with their phone?
From a security point of view, does the QR code belong to the parking company? Could someone malicious have stuck this code onto the machine?
Unfortunately, there is a problem with the QR code that rang instant alarm bells in my mind.
I spotted instantly that it isn’t using an HTTPS URL:
For a site which asks for a password – and later for credit card details – that seems like a worrying oversight, and isn’t going to instill confidence.
In fairness, the site does automatically redirect to the SSL version – but why leave that out of the QR code?
After scanning the code with their mobile phone, this is what the first time user sees:
One thing to note is that most mobile phones won’t display the full URL, unless they are in landscape mode.
The URL on display could easily be:
If you’ve never used the system before, you need to register on this screen:
It is, in my opinion, a very poor idea to require someone to type their credit card number into a phone.
- What if there’s a gang of vicious hoodies waiting to snatch credit cards from unsuspecting users as they get them out on the street?
- Is this really a legitimate site? There is no way of knowing, and the switch in branding between “paybyphone” or “PayByPhone” just makes things more confusing and suspicious.
The main way of attacking a QR code is to change it. In this case, all it would take would be a large sticker placed on the car parking notice to successfully redirect the user.
In the most mundane case, an attacker could ask the user to visit a malicious website which collects their login details – or worse, their credit card number.
However, a QR code can also be used to point to a premium rate phone number or premium rate SMS. Both could look “legitimate” when placed near a parking meter. A simple and effective way to deprive a victim of their money.
QR code hijacking is very rare – but here are a few practical tips for securing a QR code payment service.
- Include signage telling the user what the code does. Otherwise the user has no way of knowing if the code should point to a URL, phone number, or SMS.
- Print the URL near to the code. This way if the code is hijacked and pointed to http://evilsite.xxx/ the user can see they’re not visiting the correct site.
- Include https in the URL. Get users used to checking for https before they interact with you.
- If possible, use a short domain. Not only will it reduce the size of the QR code, it will give your users confidence if they can see the full domain in their phone’s URL bar.
- Don’t ask a user to get their credit card out on a busy street. Use a mobile payment solution which charges to the user’s phone bill or deducts it from their credit.
QR codes provide a brand new way for people to interact with your service. Make sure that what you offer them is simple, satisfying, and secure.
Disclaimer: The author currently works for InMobi who have a mobile payments product called SmartPay. There are several other cross-network payment solutions, including Boku or Google Checkout.
17 comments on “QR code security risks in the car park”
It truly is amazing. The crazy thing is that local councils know that they should be PCIDSS. Although they are not mandated to follow the Security Policy Framework, most have a passing knowledge of HMG policy (even if it's to ignore it). An example of why basic HMG accreditation is needed for this: you can't just leave it to the civil servants.
You would not even need to go into a credit card capture site, simply ask the user to install some malware and … game over.
Anyway, what's wrong with CASH?
"Include signage telling the user what the code does. Otherwise the user has no way of knowing if the code should point to a URL, phone number, or SMS"
That's a good idea but it doesn't aid security.
"Print the URL near to the code. This way if the code is hijacked and pointed to http://evilsite.xxx/ the user can see they're not visiting the correct site."
This is pointless, an attacker could put a sticker over the URL just as easily as over the QR code. This could actually assist an attacker by lulling users into a false sense of security.
"Include https in the URL. Get users used to checking for https before they interact with you."
This site does redirect to HTTPS before the user interacts with it. Adding it in the URL will save a HTTP request but will not increase security.
"Don't ask a user to get their credit card out on a busy street. Use a mobile payment solution which charges to the user's phone bill or deducts it from their credit."
This is why the disclaimer was added!
Thanks for the comment. I'll respond as best I can.
If you tell the user that scanning the code goes to a website, yet actually scanning the code prompts them to call a premium rate number, it should alert them that something is wrong.
As for stickers, if you look at the original photo – you'll see the URL is printed sufficiently far away from the code to make it hard to manipulate both. I think that's a reasonable way to do it.
Regarding https – if the user is used to seeing "https" every time they scan the code, they may notice when a hijacked code goes to "http". A long shot though, sure.
Finally, I can assure you that my employer has no hand in my writing the article. I added the disclaimer to be upfront on my affirmations. Indeed, I'm happy to accept Google Checkout on my blog.
Using HTTPS also ensures that the DNS (or other name resolution) can't be hijacked, this is a different attack from QR code vulnerability but is probably going to become default for all sites handling sensitive data.
This is why PayPal were pushing for changes that allow servers to say "always use HTTPS to talk to me" after the first access (see HSTS). In such a scenario once you've visited Paypal if you then access a network with compromised DNS server with a fake PayPal.com record, your browser will already know to request the HTTPS version even though there is a fake site is HTTP and hopefully barf when the certficate fails to match (although these days seems we are losing a CA a week).
I note that the domain pbp.co.uk has been registered and is convincingly similar enough to PayByPhone that it could be used in a man-in-the-middle attack along the lines you describe.
A QR code sticker placed over the top, linking to https://m.pbp.co.uk/ (user is falsely comforted by seeing https and the whole URL) which proxies to m.paybyphone.co.uk and copies card etc. details on the way through.
As ever, we must rely on common sense and cautiousness.
The ZXing Barcode Scanner (Android) shows the URL after scanning a QR Code. You can choose to open it with a browser or you can just cancel out by hitting the back button.
It's interesting how different QR scanners do this. Some will show you the code, some take you straight there. Some will send the code that you scanned to a 3rd part website for "analytics".
Always choose one which tells you were you're going.
What does "SMS" mean? If your purpose in writing is to communicate, please do not use undefined acronyms.
I think there are very few people left in the world who don't know what "SMS" stands for, or at least understand what it means.
Do you also want the author to spell out what "HTTPS" stands for? How about "QR code"?
Most Americans don't know SMS, just as an FYI. Here we call it texting, unfortunately.
That's interesting – I thought SMS was a fairly global acronym.
However, given the number of Americans who define the age of their children by what "grade" they're in, or a short distance in terms of "blocks", or an area in terms of "football fields", I don't think you're entirely blameless in this game! 🙂
Thank you, sir, for your response…most helpful as usual. You are a gentleman.
I have been thinking about this post most of the day as I read it early this morning. What has happened with QR codes is that apps have, most likely without even realizing it, upended security features you get from browsers to link to a site. Scan a QR code, what harm could there be? A lot, now that I have thought about it more.
Here in the US people are struggling to get their heads around QR codes, and at the same time they are appearing more and more. Throw security issues into the mix and they will probably retreat. But then again, this is true of any new technology for people.
Having a standard where apps display the full URL, ask if you want to connect and with what browser will lead toward safer scanning.
Reading this I wonder whether you are familiar with a different method for parking and payments.
In the Netherlands one can use parkline or Brick. One can simply park, push a start button on your parkline app (android and apple), based on GPS parking spot is determined including rate and payment is done monthly by credit card or similar. On the website one can check and change information like license plate, personal info, etc… Each car has a small card under its front window with a bar code, so some-one from the local government can check whether one has paid. Really convenient
This seems to be more of a let-down in QR code scanner apps. I don’t use apps that don’t ask for confirmation before taking any action upon scanning a QR code. Sure, from the code-generation side of things, HTTPS is relatively low-hanging fruit, but we need smarter scanning apps.
The company I work for is working on integrating digital signatures into their QR code platform so that, at the very least, you’ll know if a code has been tampered with. Web browsers have the green bar for verified HTTPS certificates so why not QR codes?
QR codes are here to stay so the industry needs to come up with some sort of solution. NFC is on the horizon but requires handset manufacturers to integrate hardware. Cool tech but a ways off I think.
The scanner apps need to take more steps in protecting their users. QR codes are here to stay and they will only get more popular with time. You cannot stop code jacking, but there could be steps that the app could take like checking the URL against common phishing or malware sites before blindly launching the website.
The code creators also need to get a clue… "call to action" around QR codes is as important as printing the QR codes itself.