> Monday (November 21st) the airline was made aware of the issue<p>> Wednesday (November 23rd) resolution has already been tested and deployed<p>That's a pretty nice response time - compared to some big companies that are asking security researchers to not disclose vulnerability for six months.
The author did not mention if they were rewarded by the bug bounty program. A vulnerability of this severity surely requires a reward of some sort.<p>Does anyone have any more information about whether or not this person was compensated for their work?
Not related to the content of the article, but to the presentation: that art work in the header is spot on, except maybe for what appears to be tree branches in the window. I think we are witnessing how generative are killing photo stock business.
Not surprising, airplane wifi has always been ridiculously insecure.<p>Back in the day, when it was first rolling out, you could (theoretically ofc) join the plane's network and scan for MAC addresses, then clone someone else's for free access.<p>I think the authentication is a bit more sophisticated these days, but it's clear that these providers treat security as an afterthought. At least the one in the article had a bug bounty program and responded quickly, I guess.<p>Unrelated, I think it's funny that the AI artist put a little picture of a house on the airplane's interior wall in the article's header image. Maybe plane trips would be more bearable if the cabins didn't look like a utopian abbatoir's waiting room.
I think the way that airlines handle this is to squash as many seats together as possible so it's not possible to open your laptop to do hacking. Problem solved!
> I tried customer_id … That also worked!<p><i>What</i> did you try <i>exactly</i>?<p>There's several of these "I changed X and got Y" without ever showing what X is, just alluding to it. That grinds my gears in any blog post, perhaps only second to not stating which version/system some code is running against.
I can understand when there's a bug that causes something like this. It doesn't excuse it, but we all introduce bugs in code, and sometimes they're disastrous.<p>But this? This is just straight up careless, thoughtless design with zero regard for security whatsoever. It's inexcusable.
I's kind of incredible how common this specific kind of vulnerability is. I have to assume the developers of these systems just hope that no one will notice?
Once a user is logged in, is including their username or userID routine API responses considered bad practice? I don't see why it should be, if everything you can <i>do</i> with that username requires an active login token.<p>The fact that you could put in an email address in lieu of a username/userID seems irrelevant; lots of systems allow email addresses as a username. What stands out about this to me is:
We see in both requests the same `uxd_id` field. This looks to be a temporary login key or validation key generated by the server, that the client would probably use to validate further requests or validate a password change request from that username. It's different in the email than in the live server response so they are generated in different sessions. So...<p>1) The email reset has two calls. What does the author mean that the first call validates the user's auth? If this is a "forgot password" link for a user who's not logged in, there should be no existing auth (unless that old uxdID functions as a permanent password, but even then, it should be specific to the user). That link should go to a page that issues a new email with a temporary validation token that's tied to the specific user and then emailed back to that user's email address. Unless you could intercept the named user's email there should be no way to know the new token and reset the password.<p>2) If, on the other hand, it was a reset pass call with the user <i>already logged in</i>, why is the server not checking that uxd_id matches the active login session <i>which also matches the user whose password is to be changed?</i> What's the point of the uxd_id field in the PUT call if not to check that calling user == authorized user == user whose password should be changed? Who would write something like that? For that reason, this looks more like a backdoor for testing password resets that was unintentionally left open.<p>Am I misunderstanding something about the way this thing is taking tokens to change passwords...? Or is what's described really as simple as "system doesn't check if uxd_id matches user's email on an active session"?
When on any sort of public WiFi network, use a VPN.<p>If anyone has a story about how "that's not enough" I'm eager to hear it. Can't be too careful, can we?