Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking the largest airline and hotel rewards platform (2023)

samcurry.net

Post reply on HN
Print view View original

51–60 of 122 posts

Re: Hacking the largest airline and hotel rewards platform (2023)

#51

Post by shakna »

ddorian43 wrote: post #35
samsonradu wrote: post #31

Earlier quoted context omitted.

Also why would anyone store and read data like { 'groups': [...] } on the client-side? Session cookies are supposed to be identifiers only, with the data stored server-side.

By default sessions in Flask are stored in plaintext: > This is implemented on top of cookies for you and signs the cookies cryptographically. What this means is that the user could look at the contents of your cookie but not modify it, unless they know the secret key used for signing.

That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.

Re: Hacking the largest airline and hotel rewards platform (2023)

#52

Post by grecy »

sangeeth96 wrote: post #39

I've always felt most such rewards program portals and apps were more hack-jobs than serious applications and thus, would be riddled with issues like these. I'm from India and I see many of these sites come and go all the time but not a single one has inspired confidence in me about keeping my data safe. For example, even the topmost cards here (HDFC Diners/Infinia) have a shoddy website, mostly a reskinned version o…

> I've always felt most such rewards program portals and apps were more hack-jobs than serious applications

It’s easy to figure out which way any system goes. Does it generate revenue or cost money? The former will be a serious application, the latter a hack job

Re: Hacking the largest airline and hotel rewards platform (2023)

#53

Post by fer »

matteason wrote: post #41

This is only tangentially related but it always blows my mind how insecure airline booking portals are. For many (most?) airlines all you need is the booking reference (PNR number) and surname to log in and see flight itinerary, contact details and, in some cases, change or cancel the booking. No password or MFA needed. The kicker is that your PNR number and surname are encoded in the barcode on your boarding pass, e…

The issue here is interoperability.

PNR identifier and last name is the only reasonable key to use when a single PNR is meant to be shared among the GDS, the IT provider, the traveler and companions, hotels, car rentals companies, travel agencies and countless other players in the market (sometimes several of each at the same time).

But it's also true it relies on the traveler keeping the PNR reference secret.

Adding MFA would involve adding new segments to all sorts of EDI messages, more complex booking/ticketing/cancelling flows, and getting all those companies on the same page so shit works without impact.

It'd be possible and an impressive engineering effort, but also a royal PITA given all the moving parts in the travel industry.

The few times I had to cancel/rebook or similar I was next to the counter with my ID, but I can think that having people call you and/or send an email for you to click to confirm is easier and has less friction than revamping the whole GDS industry and their (ducks) legacy B2B interoperation.

Re: Hacking the largest airline and hotel rewards platform (2023)

#54

Post by ddorian43 »

shakna wrote: post #51
ddorian43 wrote: post #35

Earlier quoted context omitted.

By default sessions in Flask are stored in plaintext: > This is implemented on top of cookies for you and signs the cookies cryptographically. What this means is that the user could look at the contents of your cookie but not modify it, unless they know the secret key used for signing.

That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.

By default flask doesnt have a db. There is flask-sessions extensiom that does this for you.

Re: Hacking the largest airline and hotel rewards platform (2023)

#55

Post by ddorian43 »

shakna wrote: post #51
ddorian43 wrote: post #35

Earlier quoted context omitted.

By default sessions in Flask are stored in plaintext: > This is implemented on top of cookies for you and signs the cookies cryptographically. What this means is that the user could look at the contents of your cookie but not modify it, unless they know the secret key used for signing.

That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.

The cookie contents can be changed only if you know the secret config.

Re: Hacking the largest airline and hotel rewards platform (2023)

#56

Post by callmeal »

dustypotato wrote: post #43
matteason wrote: post #41

This is only tangentially related but it always blows my mind how insecure airline booking portals are. For many (most?) airlines all you need is the booking reference (PNR number) and surname to log in and see flight itinerary, contact details and, in some cases, change or cancel the booking. No password or MFA needed. The kicker is that your PNR number and surname are encoded in the barcode on your boarding pass, e…

Maybe it was after boarding the flight? I still find it convenient . It's not that hard to keep the PNR number and surname. The reason it's so open is that there's an Identity check at the next stage where you can't use them if you're faking.

The concern is more about DOSing - using a pnr and last name, you can view (and in some cases, cancel) online via the airlines web site.

Re: Hacking the largest airline and hotel rewards platform (2023)

#57

Post by [deleted] »

michaelt wrote: post #37
joatmon-snoo wrote: post #9

Earlier quoted context omitted.

Seriously! I actually can’t think of any openly documented security incident with such impressive remediation timelines. There’s a lot that has to go into fixing things on such a tight timeline too: - oncall-level alerting for your security.txt inbox - your oncall needs to either be someone who can actually take corrective action on the system in question (not easy in a large company!) or able to route the issue to t…

> - oncall-level alerting for your security.txt inbox Maybe the terminology is different in your company, but my employer has an 'operations' team which has several shifts of workers, who look after things that need 24/7 monitoring. They then triage and escalate as appropriate. That's who you'd have monitoring the security inbox, if you want round-the-clock monitoring, so nobody's getting woken several times a night…

[deleted]

Re: Hacking the largest airline and hotel rewards platform (2023)

#58

Post by shakna »

ddorian43 wrote: post #55
shakna wrote: post #51

Earlier quoted context omitted.

That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.

The cookie contents can be changed only if you know the secret config.

Or if you can bruteforce the secret, or if there's a vulnerability in the secret, or if... You're relying on the fact that the cryptography will be impregnable, rather than adopting an actual security posture.

Do not trust the data you send to a user, to remain secure.

Re: Hacking the largest airline and hotel rewards platform (2023)

#59

Post by bogtog »

Is taking the website offline really necessary? If the vulnerability has been there for 1 year or so already, what harm does it being there for 1 year and an hour do? Also, maybe it's not clear to me exactly what is getting taken down, but I'm amazed that the chain from "person reading email" to "person that is permitted to take down the website" moves so quickly (or that the latter right is given so low in the hierarchy).

Re: Hacking the largest airline and hotel rewards platform (2023)

#60

Post by shakna »

ddorian43 wrote: post #54
shakna wrote: post #51

Earlier quoted context omitted.

That's precisely why the cookie should just be an identifier, that you look up group info from the database. Because you can guarantee the cookie contents will be modified by someone at some point. Make it useful to you, useless to them.

By default flask doesnt have a db. There is flask-sessions extensiom that does this for you.

Or you can just link to a DB directly. A Flask app is just a WSGI app. You can mount and extend it with any kind of Python, no extension necessary.
Post reply on HN