When you forget to secure your database!


When I was still working in a non-tech-related job, I took on all the responsibilities I could if they involved something tech-related. That is how I ended up discovering that one of the biggest booking companies had absolutely nothing preventing anyone from reading all of their customers databases. This was mostly restaurant bookings, so it contained what you would expect: full names, phone numbers, emails, as well as the date and time of the booking and the number of people attending. Not great.

Who, what, where.

  • Booking service company.
  • Digital display company.
  • Me

How did I discover this? Well, at the time, I was working as a conference host under a woman who viewed workers’ rights laws as suggestions she could ignore at will. I spent my days being miserable, serving self-important people coffee and cake. I worked stupid hours because neither my boss nor my colleagues could be trusted to operate a projector. Anyway, we used digital boards that displayed the meetings for the current day on a big screen in the lobby, and each meeting room had a smaller screen outside its door showing the current meeting. This service was delivered by a third party.

Initially, I just restarted the machines because they were cheap mini-PCs that would overheat and struggle to display a simple webpage. They would get stuck, crash, and have other issues that a good reset usually solved.




Oh, you want access to our production database? Okidoki!

One day, all the screens were blank, and no reset would fix them. My boss wanted us to print out every meeting on a sheet of paper and tape them over the digital screens. This worked, of course, but it was extra work and did not look professional. The booking software itself functioned as expected, so the issue had to be with the digital display company. They were contacted but were slow to provide a fix.

I reached out to both third-party companies and asked for a way to get access to the same API I assumed the digital display company was using. I figured there was a REST API that required logging in or providing credentials in a GET request. I do not remember who sent it at this point, but I received a URL that, to my surprise, loaded with no apparent security at all.

https://customercompany.bookingservicecompany.se/simpleIntegration/GetCreaJson?RestaurantId=4&dateTime=2003-11-21

The URL has been modified to protect the company (which has since fixed this flaw) and to ensure I do not get in trouble.

Just loading this URL in a browser would return all the bookings for that date in JSON format. Being an aspiring little programmer, I wrote a Flask-based Python app that ran on every one of the unreliable mini-PCs and displayed the information on the digital screens while we waited for the digital display company to fix their issues. What I made was functional enough for us, but I had to make numerous updates to handle all kinds of edge cases (literally, the text would go off the edge if the person who booked the meeting had a ridiculously long name like Jolkien Rolkien Tolkien Took). I learned a ton about CSS and why you should probably use a framework if you are not a designer.




The revelation.

The sharp-eyed reader might have noticed something that took me a while to see.

If we look again at this URL, it is easy to see that manipulating it leads to different responses.

 https://customercompany.bookingservicecompany.se/simpleIntegration/GetCreaJson?RestaurantId=4&dateTime=2003-11-21

This part is especially easy to change. A different date gives a different day’s meetings.

dateTime=2003-11-21

This part is relevant if your company has multiple locations. Each location would have an ID. Changing the ID in the URL would retrieve a different set of bookings from that location.

RestaurantId=4

Later, I realized I could also change this line:

  https://customercompany

As long as I could guess a location’s name, I could retrieve all their bookings. I looked at different restaurants in my town and was easily able to guess five of them. I believe myself to be an ethical person, and using this information for malicious purposes was never an option. However, using the access to build something useful definitely was.

I wanted to build something I had often missed. Finding a table at a restaurant on a Saturday night is nearly impossible, but sometimes, if you call five restaurants, one will have an available table for an hour. I wanted to make a service that did the hard work for you. With this access, I could do what individual restaurants do when you check for availability on their pages—but for tens or even hundreds of restaurants at the same time. Imagine entering the number of people and the desired time range into a website and getting a list of restaurants that actually have a table available.




Amateur hour.

Sometimes, things do not work out the way we hope. Today, I would likely have just launched my service and negotiated later if it was discovered. But my ethical little self wanted to do the right thing, so I contacted the booking service provider with my idea and informed them of the security hole. Their response was to close the security hole and request a lot of information that my amateur, one-man show was barely able to provide. But I answered their questions, and all I got in return was that they did not want to work with me at this time.

They now have a service that does something similar to what mine would have done, and their website was registered years before I had my idea. However, their service is inadequate for any location outside major metropolitan areas. Even the largest cities in my country still do not have such a service. But I was very inexperienced and had not even purchased a cheap domain for my website, so I can understand how it looked from their perspective when some random guy wanted to collaborate.

To be fair, there were multiple issues I never got around to fixing that would have made my website less than accurate. But being locked out of the data prevented me from launching, so it remains another forgotten project. I might try contacting them again at some point.

Here is a screenshot of the front page of the website when it was live for a short time. I do not believe anyone ever got to use it.


Description