Bypassing Cinemark's Gap Restriction
Cinemark doesn’t want people to leave gap seats when reserving tickets, but not badly enough to implement a server-side check…
Cinemark uses an online seat reservation system. Presumably to maximize the amount of seats they can sell, they no longer allow a seat gap to be left when making reservations. I discovered this when trying to make reservations for a very full showing of Avengers: Endgame. The website would not allow me to choose seats that would leave one seat between me and the wall or other reserved seats. No one likes sitting next to strangers, so I decided to see if this restriction was something that might have a workaround.
It was time to fire up Burp and see what sort of requests are being made when choosing seats. I was very surprised to see that as soon as proxy intercepting was turned on, all clicks on the seat map resulted in a request to Facebook.
There is a ton of interesting information included in those Facebook requests, but I needed to stay on task if I was going to get an Endgame seat on opening weekend without having to sit next to someone with the flu or a kid that snuck in a family size bag of potato chips. The request I cared about was the one that seemingly resulted in an error message.
Interestingly enough, no requests are sent to Cinemark when the Reserve Selected Seats button is pressed (still just Facebook), leading me to believe that the error is processed client side. A big mistake.
The next step was to see what kind of request gets sent out for a valid reservation. Clicking on a seat that does not leave a gap produces a wonderful request with an abundance of human-readable parameters.
Modifying this request could result in a nice and easy bypass of the seat gap restriction; however, it is still possible that there is some validation on the server side that prevents things like this from happening. Also, the last two numbers in the SeatToHold parameter are not obvious. I decided to try another seat to see if it resulted in a pattern.
Incrementing the row number and decrementing the column number gives us a clear picture of how the seat map works. To reserve the initial desired seat of F12, the SeatToHold parameter needs to be modified to F-12-6-4. Cinemark also includes a lovely feature that allows anyone to temporarily reserve seats before actually making a purchase. This can be used to verify that the modified request works.
The first sign that the modified request works is that the resulting ticket number has been changed to F12.
Going through the seat reservation process again also shows that F12 is not available, even though it is still creating a single contiguous space in F13.
Of course the only way to truly tell if it works is by actually purchasing the ticket and showing up, but I have a feeling *wink* that it absolutely does work. I have attempted to contact Cinemark to report this issue, but they don’t seem to have taken it too seriously and I would not be surprised if the workaround persists.
As you can probably imagine, this method could be used for many malicious (and less petty) purposes. Some things off the top of my head include reserving all seats as soon as tickets open up in order to prevent actual customers from buying tickets or double booking seats to cause mayhem. It’s imperative that companies have a system in place for public reporting of bugs and take the provided information seriously.
PS. I found out later that the first two values in the SeatToHold parameter describe the seat number (obviously) and are the values printed on the ticket and in the reservation. The last 2 values are the seats that are reserved in the online seat map. Only changing one pair of values results in either duplicate tickets printed out or double booking of seats.
