61–70 of 80 posts
If you've participated in their program, you'll probably find that they have their fair share of issues. This is probably where their delay is coming from (but not a valid excuse). I found two serious problems in less than a hour. I reported the issues to them and was subsequently told that both submissions were out of scope and a firm warning to follow the rules. You're welcome for the free findings.
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.
Earlier quoted context omitted.
yes, absolutely. 2 freaked me out the most. I managed to get enterprise github installed, taught people how to use it, set up the client on their computers, pointed them at tutorials, and pestered them regularly. For all that effort, over the 6 months the adoption rate was pretty much just 1 developer in one department - me. It's just so damn hard to get people to change.
I'm in the position of trying to push towards changes just like these- introducing better issue management, team communication. Anyone aware of useful resources on rolling out institutional changes like that?
Earlier quoted context omitted.
Does the company not have any legal recourse against people going public (or threatening to go public) with a bug like this before it's fixed? If not, how is it that United can just mark unfixed bugs "as duplicates" and refuse to pay out for them? Shouldn't all those devs immediately go public with them?
There can be a fine line between full disclosure and blackmail. I would be concerned "give me airpoints or else" would go over it.
Blackmail is one of those rare crimes that consist entirely of legal conduct.
Earlier quoted context omitted.
[deleted]
Why are you looking for off-site vulnerabilities? Would this be something you did even if they weren't running a bounty? You should be careful testing sites out of scope. The bounty gives you implied permission to test for vulnerabilities on sites in-scope, but "I was just security testing" is demonstrably not sufficient to insulate you from civil litigation or even criminal charges --- you would probably win in cour…
If you've participated in their program, you'll probably find that they have their fair share of issues. This is probably where their delay is coming from (but not a valid excuse). I found two serious problems in less than a hour. I reported the issues to them and was subsequently told that both submissions were out of scope and a firm warning to follow the rules. You're welcome for the free findings.
It's pretty ridiculous that actual problems are "out of scope".
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.
It's unreasonable for anyone, no matter how big and bureaucratic they are. The fact that they're bloated and incompetent doesn't excuse their incompetence.
I have similar problem with one of the Salesforce's subdomains. Report accepted and assigned status low. 7 months later XSS is still there.
Not sure what to do by now.