As I said in the Post, it is not a security vulnerability itself, but I want to point out that it can be very dangerous to put a password in a GET request. And the response of ebay is bad too. But thank you for your constructive comment ;)

If you're on https ebay, sending GETs to https ebay then the GET parameters are not sent in plain text. The owasp article you link to mentions that GETs can be sent in clear when you have a mixed http/https scenario. I think your screenshots are a little misleading, as not all of the headers and information you show are sent in the clear when using TLS. The response of ebay seems OK, this isn't a big issue at all.

EDIT: Sorry for the misunderstanding: as mentioned elsewhere, the problem is not so much the user-agent end, but the hops between where the decryption happens and where the information is used. Why expose the information more than needed there? So I guess ebay's response is a bit lacking. They could make things more secure with relatively little effort.

>> I guess ebay's response is a bit lacking

Except that ebay's response was to the POST over https he mentions in the first section of his article. There is absolutely nothing at all suspicious about that. He wasn't looking into a potential security hole there, he was just prodding as to why they do server-side validation in a completely secure manner. His email had nothing to do with security; he was wasting someone's time asking about implementation details.

He then went on to find a GET version in another area on the site, for which he makes no mention of having sent an email. This might not be considered a security problem to ebay depending how they manage web server logs, but it's certainly a viable inquiry compared to the POST version he did email about.

He's got a point that sending via GET is kinda dirty. I'd hope ebay logs don't log the full url of requests. Sure, getting to those logs would be super difficult, but you really don't want plain text passwords anywhere.

In general though, yeah, not that exciting of an article.

They're embedding the password in a GET request. That'll get logged all over the place.

But GET arguments are not visible to 3rd parties when using https. Anything after the host name is sent encrypted.

Https is often terminated at a relatively early point, eg the load balancer, so that the request can be properly routed. (Eg if you use AWS, it's generally terminated at ELB). That means the request path may be logged by the load-balancer and whatever routers/proxies they're using, as well as in the request logs of the web server itself.

It's completely unnecessary to have everyone's passwords be viewable by however many people have access to one or more of those logs (for a org the size of ebay, maybe 10-100 people?).

Sure, it's not as terrible as if it was sent over http, but 'not being as the worst it could possibly be' isn't a very high bar.

Are you implying that POST data isn't going to be transmitted in cleartext beyond that point? Because that's incorrect - HTTPS doesn't selectively encrypt - the whole connection is encrypted. If you're worried about GET data being sent in cleartext, POST is no different.

The point is that GET parameters are more likely to be stored in server logs or other application logs where POST body is usually discarded from such logs.

So someone getting access to the logs will have access to a lot of possibly sensitive data, that's all depending on server and application settings, but by default GET are more likely to leave traces than POST.

It's a subtle but valid concern.

Ahhh, understood. There's someone between what you see as "ebay.com", where the GET is decrypted, and the actual ebay machine that will use the password information. I was thinking of it at the user-agent level. The GETs never leave your machine in plain text. I did not consider that the other end where you send the information could be "flakey". Bloody hell, it's a miracle anything works at all.

Not even necessarily, but the https logs are likely archived to another server, and that server will likely be secured completely differently.

Maybe ebay do the right thing and terminate on the final endpoint, and keep their logs appropriately secured. We shouldn't assume the worst without knowledge.

It's not so much the HTTPS but the logs, the server logs are not necessary designed to store all the users passwords.