The author is being nice calling it a bug. A buffer overflow is a bug. This is a moronic design, like a sql vulnerability. I am shocked that in these days and age, so many web developers have not adopted the mentality "everything coming back from the client may and will ultimately be tainted". Relying on an ID provided by the client without checking the appropriate access is unexcusable. How many years ago was the Dell shopping cart bug (where a client could alter the price of an order)?
United Airlines Bug Bounty: An experience in reporting a serious vulnerability
71–80 of 80 posts
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#72If 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.
If only TSA considered security out of scope, and settled on a firm warning to follow the rules.
Sure, planes may not fall out of the sky through webservice vulnerabilities, but but you'd think airlines would be slightly more aware of how security works.
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#73Earlier 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?
Is there a kind of "union" for bug finders, some corporate shell anonymous hackers can hide behind to avoid legal crushes?
Anonymous hackers just use a mask. Sorry, I couldn't resist.
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#74> Using just these two values, an attacker could completely manage any aspect of a flight reservation using United’s website.
Don't most airline websites allow that when you get the last name and date of departure right?
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#75> Using just these two values, an attacker could completely manage any aspect of a flight reservation using United’s website. Don't most airline websites allow that when you get the last name and date of departure right?
Yes. But the point is that he was able to gain these two bits of information.
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#76The author is being nice calling it a bug. A buffer overflow is a bug. This is a moronic design, like a sql vulnerability. I am shocked that in these days and age, so many web developers have not adopted the mentality "everything coming back from the client may and will ultimately be tainted". Relying on an ID provided by the client without checking the appropriate access is unexcusable. How many years ago was the De…
It's frequently scarier than that. I've seen applications do the right thing by IDs and queries, but then attempt to audit access and not correctly escape or sanitise HTTP headers.
Literally, every single piece of information that an application receives is not to be trusted. Even if it's something you think you have set and have full control of (a cookie value), you're wrong... you have no control, and attackers can and will manipulate every field or property to gain a foothold.
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#77The author is being nice calling it a bug. A buffer overflow is a bug. This is a moronic design, like a sql vulnerability. I am shocked that in these days and age, so many web developers have not adopted the mentality "everything coming back from the client may and will ultimately be tainted". Relying on an ID provided by the client without checking the appropriate access is unexcusable. How many years ago was the De…
It's frequently scarier than that. I've seen applications do the right thing by IDs and queries, but then attempt to audit access and not correctly escape or sanitise HTTP headers. Literally, every single piece of information that an application receives is not to be trusted. Even if it's something you think you have set and have full control of (a cookie value), you're wrong... you have no control, and attackers can…
Actually, case in point... X-Forwarded-For. This is not in a spec, people are using it as an unofficial standard. But so long as your edge removes it and then sets it... you're good.
Except Google are doing their page speed optimisation thing in the style of the Opera Mini proxy, but for Chrome users on Android. Google have chosen to populate X-Forwarded-For, so any website that wants to audit the IP address of an end user now has to read this untrusted header.
So devs will realise this, look at the header, stop stripping it at the edge, and start trusting what is essentially a string that anyone can set.
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#78It's so funny to see how surprised people are about the "corp" IT compared to the "free" IT world. Once I was also surprised about how long it takes and that very important things can be out of scope.
I think the reason is that in fact in teams >10 people nobody really knows what's going on. That anything happens is more the result of many attempts and some luck. That nothing succeeds is the default.
Think of it more as "Twitch Programs Flight Ticketmanager App" than actual software development as you read it in a book. (I once worked with >5 other guys on getting a string in one computer pointing to another computer, took the whole week)
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#79Earlier quoted context omitted.
It's frequently scarier than that. I've seen applications do the right thing by IDs and queries, but then attempt to audit access and not correctly escape or sanitise HTTP headers. Literally, every single piece of information that an application receives is not to be trusted. Even if it's something you think you have set and have full control of (a cookie value), you're wrong... you have no control, and attackers can…
Actually, case in point... X-Forwarded-For. This is not in a spec, people are using it as an unofficial standard. But so long as your edge removes it and then sets it... you're good. Except Google are doing their page speed optimisation thing in the style of the Opera Mini proxy, but for Chrome users on Android. Google have chosen to populate X-Forwarded-For, so any website that wants to audit the IP address of an en…
I like the way IRC networks handle this, they use a pre-connection protocol verb called WEBIRC (de-facto standard documented here: http://git.io/vBLYp) that also enforces a whitelist of ip address + password combination. This stops most abuse of this feature. Maybe HTTP servers should have something similar.
Re: United Airlines Bug Bounty: An experience in reporting a serious vulnerability
#80The author is being nice calling it a bug. A buffer overflow is a bug. This is a moronic design, like a sql vulnerability. I am shocked that in these days and age, so many web developers have not adopted the mentality "everything coming back from the client may and will ultimately be tainted". Relying on an ID provided by the client without checking the appropriate access is unexcusable. How many years ago was the De…
> How many years ago was the Dell shopping cart bug (where a client could alter the price of an order)?
Sounds like every third-party shopping cart I've ever looked at except FoxyCart, and even then this behavior is the default.
(I've heard people refer to this as "that bug shopping carts have." It seems people overwhelmingly prefer catching this with "fraud detection".)