Hacker Newsnew | past | comments | ask | show | jobs | submit | slashcrypto's commentslogin

They said, that they are looking into it ...


Would be very interesting to know what SFFE means ;)


I'm pretty certain it's a server name.

It's a similar convention as some of their other names such as GRFE (Groups), bsfe (Blog Search Front-End).

https://googlesystem.blogspot.com/2007/09/googles-server-nam...


Static File Front-End?


The hostname is static.corp and the service is static-on-bigtable, so...


I edited this part, you are definitely right.


I edited the article because I really missed this point, you are right. I thought WhatsApp is not sending the message which got encrypted with the new key. But still, I would not say this is a backdoor, because the user has a relatively easy way to check the keys. If WhatsApp would like to implement a backdoor, they would have done it in a different way I think.


you got a point, i will do a short edit here.


what do you mean? normally passwords are not stored in logfiles ...


"Normally" ? What refrain you from logging HTTP Body ? It's the same problem as logging HTTP query string. You should consider everything you send over HTTPS public for the receiver in any way.


The passwords are not necessarily being captured in logfiles, that's a huge assumption. We don't know anything about how eBay stores and manages their web server logs.


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: