21–30 of 80 posts
Interesting terms, if you can't talk about it afterwards how do people know that any of these bounties were paid out? After all there is a pretty simple loophole here: mark any and all reports as duplicates, no need to pay out.
[deleted]
Mine was a duplicate as well. Anyone here who was paid out?
Is six months really unreasonable for a big bloated bureaucracy like United Airlines? I've worked on projects for smaller tech companies with release cycles longer than that. Not defending--obviously they should be set up to be able to put out small emergency fixes quickly especially if they're running a bug bounty. But, hey, it's an airline: releasing software is not exactly their bread and butter.
Let's rephrase your question: "Is six months really unreasonable for an airline to fix a vulnerability that allows customer data to be stolen?" Yes, I would say so.. especially since this is a 'duplicate' meaning that multiple people were already aware of this, and on top of that it seems the only reason it was eventually fixed was because they couldn't delay fixing the problem any more. I don't think anyone would co…
Is six months really unreasonable for a big bloated bureaucracy like United Airlines? I've worked on projects for smaller tech companies with release cycles longer than that. Not defending--obviously they should be set up to be able to put out small emergency fixes quickly especially if they're running a bug bounty. But, hey, it's an airline: releasing software is not exactly their bread and butter.
On the bug difficulty totem pole, this one hangs rather low. Hell, they even claimed it was a duplicate report.
I'm surprised the newspaper didn't run the story anyways, because on a data leak bug like this the work isn't done when you patched the original problem, only when you have combed through all the application logs, identified malicious requests and notified customers and authorities of possible leaks can you claim to have dealt with the issue at hand.
(Yes, if your app server isn't logging all requests, you should probably start today, otherwise you end up like the NSA when Snowden took off and you first learn of lost data when it appears in a newspaper)
Interesting terms, if you can't talk about it afterwards how do people know that any of these bounties were paid out? After all there is a pretty simple loophole here: mark any and all reports as duplicates, no need to pay out.
Is six months really unreasonable for a big bloated bureaucracy like United Airlines? I've worked on projects for smaller tech companies with release cycles longer than that. Not defending--obviously they should be set up to be able to put out small emergency fixes quickly especially if they're running a bug bounty. But, hey, it's an airline: releasing software is not exactly their bread and butter.
Let's rephrase your question: "Is six months really unreasonable for an airline to fix a vulnerability that allows customer data to be stolen?" Yes, I would say so.. especially since this is a 'duplicate' meaning that multiple people were already aware of this, and on top of that it seems the only reason it was eventually fixed was because they couldn't delay fixing the problem any more. I don't think anyone would co…
Earlier quoted context omitted.
Let's rephrase your question: "Is six months really unreasonable for an airline to fix a vulnerability that allows customer data to be stolen?" Yes, I would say so.. especially since this is a 'duplicate' meaning that multiple people were already aware of this, and on top of that it seems the only reason it was eventually fixed was because they couldn't delay fixing the problem any more. I don't think anyone would co…
Which makes you wonder if person #3 or higher submitting this bug couldn't sell it since they are not getting a bounty. Six months is a long time to leak customer information.
Is six months really unreasonable for a big bloated bureaucracy like United Airlines? I've worked on projects for smaller tech companies with release cycles longer than that. Not defending--obviously they should be set up to be able to put out small emergency fixes quickly especially if they're running a bug bounty. But, hey, it's an airline: releasing software is not exactly their bread and butter.
>But, hey, it's an airline: releasing software is not exactly their bread and butter. it's not pilots and flight attendants coding that application. they've got an IT department whose bread and butter IS releasing software.
I don't think you've dealt with UA much...
Earlier quoted context omitted.
Bloated beauracracies need agile ways to respond to important situations. Giving them a pass because they are bloated won't make that happen any sooner, and it does need to happen.
Organizations like that have no code hygiene. They have smart talented people that are entrenched in their way of doing things. They don't have the money to throw the code away and start over. They don't have the control to enforce code standards. There are a couple of terrible effects that slow them down. I'll bet you a nickel that the json is generated by a stored procedure. In that kind of environment, you can't r…
I'm not saying these companies need to magically become less bloated, but they do need fix security problems with the urgency they require. If that means that we all need to make a stink so it starts actually seeming important to them, then so be it. Another way to look at this is that they've reaped the benefit of having a web presence for years, but haven't had to pay some of the associated costs (since they apparently don't have the internal structure in place to review and/or fix these problems). In that respect, they've been playing the odds for a long time and come out ahead (wittingly or not), but that doesn't mean they don't need to pay up when it bites them in the ass.