Recently, the latest website security saga in the news has been Hotelhippo.com. I won’t try and top Scott Helme’s article as he does an excellent job at explaining the saga in exhaustive detail, along with the other glaring issues he discovered. There’s another great article by Neil Stud that is definitely worth a read too. However, I’ll be covering the issue purely from a web development perspective, because as a developer myself, I find the whole situation scary/insane.
The issue I will be covering concerns an error that any web developer, even a junior, cannot excuse – the ability to change query string data and view private information without authentication. A site as big as Hotel Hippo and one that that stores a lot of personal customer information should frankly, be ashamed of themselves for such a basic breach.
The main insecurity that Helme points out regards the ability for an unauthorized user to tamper with query string variables. Granted, none web developer types may not ever think to tamper with this data. However, the fact it is possible makes this flaw very serious. The developer/agency who created the site should be frankly ashamed.
Assume there is some sort of basic order page, where a customer can click a link to view order details – pretty common yes? Lets say the link to the order is http://site.co.uk/customers/order/1234, where 1234 is the order number. Any sane developer should be checking the following as a minimum:
- Is the customer logged in?
- If #1 is true, does the order number from the query string belong to the logged in customer. If not, do not display the order
Completely off topic, for the latter I’d use a custom route filter if using Laravel 4, and quickly apply this to the order detail route. But I digress 🙂
The developer(s) at Hotel Hippo have decided, in their vast wisdom, to blindly display this data to anyone viewing the site. So in the latter example url if I wanted to view order #1000, I’d quickly change the url to http://site.co.uk/customers/order/1000 and then http://site.co.uk/customers/order/1001 and so on.
I’d hate to see some sort of system created by the Hotel Hippo web developers that involves users editing their profile. Would they put the basic check in place to check that as a logged in user, I can only edit my own profile? Based on the evidence, probably not 🙂
Helme identified two entry points for this vulnerability on the Hotel Hippo website:
During the checkout process, as an unauthenticated user, you are redirected to an url similar to https://secure.hotelhippo.com/PaymentProcess.aspx?referenceNumber=HHU_47613. It turns out anyone can alter the “referenceNumber” variable (which worse still, is sequential) and view other people’s booking information!
Upon making a booking (assuming you’re brave enough to do so on the Hotel Hippo website …) you are sent a confirmation email, with a link to your booking summary/confirmation. Again, no authentication and the ability for any user to change the variable in the query string. This time though more details are visible: your address, your hotel, the amount you spent. Shocking. As Helme points out, an attacker could now call up a customer, posing as Hotel Hippo and extract customer card details easily. To a customer, a call like this would be very convincing as the attacker has a serious amount of legitimate information about the customer/booking. Hell, the attacker could mention there is some sort of issue with the booking and they need to verify your card details. Very scary stuff. Even more scary, is it wouldn’t take much effort to write a small script to sequentially collect a lot of this data, due to there being zero authentication.
Even more scary is Google Indexing. As the Hotel Hippo web developer decided to not block/noindex order pages Google has actually indexed urls like https://secure.hotelhippo.com/PaymentProcess.aspx?referenceNumber=HHU_47613 – private booking information indexed within Google – insanity.
All of which could be avoided by a simple check and some sane web development!
Ironically, at the top of the ordering screen, the site displays a very visible message informing the user that they are on “a secure connection”. Using SSL won’t help one bit in this instance. Even more ironically still, regards the fact that the SSL isn’t setup to use the latest security protocols and is therefore in breach of PCI compliance. Ouch.
What the web developer was thinking pushing out a site with such a glaring security hole, is literally beyond me. I’m in disbelief.
What makes me a chuckle a little is the fact that Hotel Hippo use ASP.NET. Seemingly, whenever I meet an ASP.NET developer, they always ramble on about how utterly insecure PHP is, how awful it is – as I’m primarily a PHP developer. The Hotel Hippo saga proves that any language is insecure if in the hands of a developer who is not thinking logically at all.
As of 12/07/2014 hotelhippo.com has a message saying it has been permanently shut down, yikes!
More recently, HotelStayUK (the owners of Hotel Hippo) issued a statement:
HotelHippo has shut down and will not reopen. Our investigations showed that just 24 customers were affected by the issues with HotelHippo. This was a small very little used site. But for even one customer, it is obviously completely unacceptable and we are very sorry. We have therefore contacted all these customers and have offered them compensation. We have also set up a helpline where customers can contact us by calling 08446 606 007.
Security of our customers’ data is of the upmost importance to us. Despite there being no issues with our other sites, as the login process is quite different, as a precaution, we advised affected customers and took down all sites in the group one by one to put them through rigorous testing by independent experts to ensure their safety and security. These independent experts will be employed on an on-going basis to regularly test our sites.
It sounds like Hotel Hippo don’t feel they can fix the issues, or are not willing to.
After reading Helme’s article, the changes required to fix the immediate issues aren’t huge in my opinion:
- Only display the “Secured by Comodo” badge on SSL enabled pages, as the SSL certificate is only authorised for the secure.* domain
- Authenticate users before viewing booking / payment confirmation pages. For the checkout process, I see little need to display the booking number in the url at all
- Configure the SSL certificate to make the site PCI compliant
- Noindex all order detail pages and submit url removal requests to Google (even though the site offline, these links need to be removed from Google’s cache quickly)
- Sanitise user input (* facepalm *)
However, the issues identified may only be the tip of the iceberg. I wouldn’t be surprised at all for other issues to popup. The site needs extensively testing and reworking from the ground up. I wouldn’t say that if the “bug” identified was very obscure as opposed to a school boy error.
What are your thought’s on the HotelHippo.com saga?