When I republished my article “Bypassing a Login Form using SQL Injection“, it received a mixed reception. While some applauded the effort to raise awareness on bad coding practices leading to serious security vulnerabilities (which was the intent), others were shocked. Comments on the articles and on Reddit were basically variants of “That code sucks” (of course it sucks, that’s exactly what the article is trying to show) and “No one does these things any more”.
If you’ve had the luxury of believing that everybody writes proper code, then here are a few things (limited to my own personal experience) that I ran into during 2016, and in these first few days of 2017.
SQL Injection
I was filling in a form on the website of a local financial institution a few days ago, when I ran into this:
It was caused by the apostrophe in my surname which caused a syntax error in the SQL INSERT statement. The amateur who developed this website didn’t even bother to do basic validation, let alone parameterised queries which would also have safeguarded against SQL injection.
Airlines and Apostrophes
My experience with airlines is that they tend to go to the other extreme. In order to keep their websites safe, they simply ban apostrophes altogether. This is a pain in the ass when your surname actually has an apostrophe in it, and airlines stress the importance of entering your name and surname exactly as they show on your passport.
United Airlines, for instance, believe that the surname I was born with isn’t valid:
Virgin America, similarly, takes issue with my whole full name:
We’re in 2017. Even shitty Air Malta accepts apostrophes. All you need to do is use parameterised queries or a proper ORM. Using silly and generic error messages doesn’t help avoid customer frustration.
Plagiarism
Speaking of Air Malta, here’s a classic which they ripped off from some other US airline:
US Federal law? In Malta? Go home, Air Malta. You’re drunk.
Don’t Piss People Off
I’ve had a really terrible experience with booking domestic flights with US airlines. There is always some problem when it comes to paying online with a VISA.
United Airlines, for instance, only accepts payments from a specific set of countries. Malta is not on that list, and there is no “Other” option:
Delta gives a variety of billing-address-related errors depending on what you enter.
Southwest provides fields to cater for payments coming from outside the US:
And yet, you need to provide a US State, Zip Code and Billing Phone Number.
The worst offender, though, is Virgin America. While the overall experience of their AngularJS website is quite pleasant, paying online is a hair-ripping experience. If you choose a country where the State field does not apply (such as Malta, or the UK), a validation error fires in JavaScript (it doesn’t appear in the UI) and does not let you proceed:
It’s almost like the developers of this website didn’t quite test their form. Because developers normally do test their code, right? Right?
Well, when I reported the error to Virgin, and offered to provide a screenshot and steps to reproduce, the support representative gave me this canned bullshit:
“So sorry for the web error. Can recommend using one of our compatible browsers chrome or safari. Clearing your cookies and cache. If no resolve please give reservations a ring [redacted] or international [redacted] you’ll hear a beep then silence while it transfers you to an available agent. Thanks for reaching out.~”
I had to escalate the issue just so that I could send in the screenshot to forward to their IT department. Similarly, I was advised to complete the booking over the phone.
Over a month later, the issue is still there. It’s no wonder they want people to book via telephone. Aside from the international call rate, they charge a whooping $20 for a sales rep to book you over the phone.
Use SSL for Credit Card And Personal Details
In July 2016, I wanted to book a course from the local Lifelong Learning unit. I found that they were accepting credit card details via insecure HTTP. Ironically, free courses (not needing a credit card) could be booked over an HTTPS channel. When I told them about this, the response excuse was:
“This is the system any Maltese Government Department have been using for the past years.”
It is NOT okay (and it’s probably illegal) to transmit personal information, let alone credit card details, over an insecure channel. That information can be intercepted by unauthorised parties and leaked for the world to see, as has happened many times before thanks to large companies that didn’t take this stuff seriously.
To make matters worse, Lifelong Learning don’t accept cheques by post, so if you’re not comfortable booking online, you have to go medieval and bring yourself to their department to give them a cheque in person.
I couldn’t verify if this problem persists today, as the booking form was completely broken when I tried filling it a few days ago – I couldn’t even get to the payment screen.
Update 8th January 2017: I have now been able to reproduce this issue. The following screenshots are proof, using the Photo Editing course as an example. I nudged the form a little to the right so that it doesn’t get covered by the security popup.
Update 9th January 2017: Someone pointed out that the credit card form is actually an iframe served over HTTPS. That’s a little better, but:
- From a security standpoint, it’s still not secure.
- From a user experience perspective, a user has no way of knowing whether the page is secure, because the iframe’s URL is hidden and the browser does not show a padlock.
- The other personal details (e.g. address, telephone, etc) are still transmitted unencrypted.
Do Server Side Validation
When Times of Malta launched their fancy new CMS-powered website a few years ago, they were the object of much derision. Many “premium” articles which were behind a paywall could be accessed simply by turning off JavaScript.
Nowadays, you can still access premium articles simply by opening an incognito window in your browser.
Let’s take a simple example. Here’s a letter I wrote to The Times a few years ago, which is protected by the paywall:
Back in 2014, I used to be able to access this article simply by opening it in an Incognito window. Let’s see if that still works in 2017:
Whoops, that’s the full text of the article, without paying anything!
Like those critics of my SQL injection article, you’d think that people today know that client-side validation is not enough, and that it is easy to bypass, and that its role is merely to provide better user experience and reduce unnecessary roundtrips to the server. The real validation still needs to be server-side.
Conclusion
Many people think we’re living in a golden age of technology. Web technology in particular is progressing at a breathtaking pace, and we have many more tools nowadays than we could possibly cope with.
And yet, we’re actually living in an age of terrible coding practices and ghastly user experience. With all that we’ve learned in over two decades of web development, we keep making the same silly mistakes over and over again.
I hope that those who bashed my SQL injection article will excuse me if I keep on writing beginner-level articles to raise awareness.
