Since the email requires a static link, HTTP POST web requests are not really an option, meaning the booking reference code and the email are passed as arguments in the URL itself. On its own, this would not be an issue. However, many sites directly load additional content on the same website, such as advertisements. This means that direct access is shared either directly with other resources or indirectly through the referrer field in the HTTP request. My tests have shown that an average of 176 requests are generated per booking, although not all these requests contain the booking details. This number indicates that the booking data could be shared quite widely.
To demonstrate, let's assume the confirmation email contains a link in the following format, which would automatically log me into my booking overview:
- https://booking.the-hotel.tld/retrieve.php?prn=1234567&[email protected]
The loaded page, in this case the retrieve.php website, may call many remote resources. Some web requests made for these external objects will directly send the full URL, including the credentials, as a URL argument.
The following is an example of an analytics request, which contains the full original URL including the arguments as an argument on its own:
As mentioned, the same data is also in the referrer field, which will be sent along by the browser in most cases. This results in the reference code being shared with more than 30 different service providers, including well-known social networks, search engines, and advertisement and analytics services. This information could allow these third-party services to log into a reservation, view personal details, and even cancel the booking altogether.
Note that in this scenario, the fault is not on the service provider's side.
There are other scenarios in which the booking data may also be leaked. Some sites pass on the information during the booking process, while others leak it when the customer manually logs into the website. Others generate an access token, which is then passed in the URL instead of the credentials, which is not good practice either.
In most cases, I found that the booking data remains visible, even if the reservation has been canceled, granting an attacker a large window of opportunity to steal personal information.
Hotel comparison websites and booking engines appear to be slightly more secure. From the five services that I tested, two leaked the credentials and one sent the login link without encryption.
It should be noted that I identified some well-configured websites that digest the credentials first and then redirect after they set a cookie, ensuring data isn’t leaked.
It could be argued that the privacy risk with this issue is low given the data is only shared with third-party providers that are trusted by the websites. However, it is concerning that I found more than one-quarter (29 percent) of the hotel sites did not encrypt the initial link sent in the email that contained the ID. A potential attacker could therefore intercept the credentials of the customer who clicks on the HTTP link in the email, for example, to view or modify his or her booking. This may occur at public hotspots such as the airport or the hotel, unless the user protects the connection with VPN software. I also observed one booking system that leaked data during the booking process to a server over HTTP before the connection got redirected to HTTPS.