The curse of learning how to spot security and privacy holes in software is that you can’t start unseeing them. Ever the eternal optimist, I try to report them as a service to system users, even though sometimes I am either ignored, or receive abuse for my troubles.

In this case, getting the Queensborough Group to answer mail sent from their online form is proving to be a bit of a hassle. They have a leaky hotel review form in their software, which spits out names and email addresses upon provision of a trivial sequential primary key. However, they seem to unfortunately struggling to send acknowledgements to my reports – perhaps they are valiantly toiling to fix the bugs?

I am guessing Booking.com are a data feeder into this system, so I will see if I can get the security peeps at that organisation to apply some encouragement. A good proportion of the email addresses exposed in the review form look like they have been auto-generated at Booking.com just to ensure the data record is accepted when it is pushed.

Below are the messages I have sent to QG.

15th August 2022:

Hi peeps

I have noticed some security problems with your hotel review form, and I wanted to let you know, so you can fix it. Could I trouble you to forward my message to your technical team?

The problem is three-fold:

• Customer IDs are predictable integers
• Customer names and email addresses are displayed on-screen
• I would guess unauthorised reviews could be added by anonymous internet users, where the customer has not added a review themselves (I have not tried this)

The format of the URL looks like this:

https://secure.hotels.uk.com/review.php?ID={hotelId}{customerId}

For example:

• xxxxx is the hotel ID for a (pretty good) hotel in Isle of Anglesey
• yyyyyy is my customer ID for when I stayed there

I assume that the hotel IDs are guessable too, and thus customers from other hotels could be retrieved.

I expect a review can be created merely by running a POST action against the same URL, and filling in the expected data (though it looks like the system might reject duplicate reviews).

I have every confidence that your technical team can plug the security holes, but for what it is worth, I would fix it in the following way. In the review email, send two query strings in the link: ID (which you already have) and HASH (which would be new). HASH would be something like a SHA256 hash of the customer’s email address plus a predictable salt (e.g. the ID). When the page is rendered, calculate the hash on the server, and throw a 404 if the supplied HASH does not match it (for any HTTP method).

Given that this is a fairly obvious GDPR hole, I wonder if it is worth getting in a qualified security reviewer for the rest of the site? (For the sake of clarity, I do not know of any such firms myself, but I expect your technical team can find one).

Kind regards,

3rd September 2022:

Hi there

I sent to you an email a few weeks ago regarding a data exfiltration issue in your online hotel booking software, and I don’t appear to have heard from you. Would you get in touch please?

I would be most grateful for a prompt response, as is customary for software security reporting.

Kind regards,

17th September 2022:

Hi folks

I have been in touch lately via web form to raise a security and GDPR issue with your website. I sent messages to you on 15th August and 3rd September, but have not received replies to these messages.

Since the data leak appears to affect reservations from booking.com, and since you had ample time to fix the leak, I will notify their security team this weekend. I will aim to raise a complaint with the Information Commissioner at the end of the month. Do please get in touch.

Kind regards,

Next steps:

• Working out how to contact the Security Team at Booking.com (!)
• Compile a report for Booking.com
• Write to the hotel I stayed at (they can raise a support request)
• Information Commissioner

It looks like Booking.com don’t participate on HackerOne, though to be fair to them, the bug I’ve found isn’t of their making.