Hacker News new | ask | show | jobs
by leejo 2226 days ago
Possible, maybe not even hashed?

Given the disallowed chars that's suggestive that the form used to be implemented as a GET, so it's possible passwords were in log files for a long time.

1 comments

Is there a technical reason to use a GET for authentication? I've always seen it as a POST. If you use GET, won't your parameters be plainly visible in well, everything, unless they put them in the body and that's a whole nother can of worms.
No, https encrypts the URL as well (although the domain itself can be leaked via DNS). But in most respects query params are no different to the body security wise. The main difference is that if you bookmark it, you may end up storing your sensitive data in your bookmarks.
Query params often end in stuff like web server (WAF, load-balancer, reverse proxy, ...) access logs and they might get accidentally exposed.

They shouldn't get exposed of course, but they do. [EDIT: redacted an example of some random dude's access log]

If you search for "password" in there you will likely see a new Mirai bot variant [1] bouncing credentials off the server looking for weblogin.cgi on vulnerable Zyxel devices.

I imagine PA highlit this detail in their post ("weblogin.cgi accepts both HTTP GET and POST") exactly to ensure sure defenders don't restrict themselves to blocking or investigating only the more normal POST mechanism.

[1] https://unit42.paloaltonetworks.com/new-mirai-variant-mukash...

Yeah that's a fair point. So the security is worse in that sense, so many ways to leak it. It'd be insanity to put sensitive info in the query params either way. It's just not the appropriate place for them.
I had no clue the URL was encrypted too. So how does DNS work? Or does it send through plaintext the name of the server, and the rest of the URL has to be encrypted by the endpoint.
The domain name is not encrypted, but the path and querystring are.

So, a spy watching your https traffic knows that you're interacting with news.ycombinator.com (and possibly other things), but they don't know anything that goes after the `/`: which thread, whether you're POSTing or GETting, or of course any of the content.

I have definitely seen some sites using GET for authentication, they tend to be ones that have been around for a long time and haven't been fixed. Can't remember the last time I saw this though.

I'm not sure when easyJet first started using online accounts, but "you can't use some URI query reserved chars" does seem like a strong indicator there used to be a GET involved.

No. GET params in the URL should not have security-sensitive data this wasn't always widely known. Even in HTTPS-everywhere world, there are still security implications.

Early versions of some PHP sites, for example, would pass around auth tokens (think the auth cookie) in a URL. This soon became an obvious problem when users copy-pasted their URLs into forum posts, non-HTTPS URLs were logged by proxies, and web server access logs became gold mines for maybe-still-active sessions.