[brown9-2]

Parameters sent via GET can get cached by proxies and they appear in log-files.

Not to argue in favor of sending sensitive data via GET, but I think it is worth pointing out that third-party proxies cannot see the URL or other parts of the HTTP headers or body when the connection is using HTTPS.

[arviewer]

But there is a good chance that these GET parameters are logged by the webserver. Even if these servers are very secure and strictly monitored, one bad employee can cause a lot of trouble.

[Someone1234]

Perhaps, but an employee in that position can steal credentials even without GET logs.

This entire discussion is predicated on a contradictory assumption, that an employee would be corrupt enough to steal credentials from web server logs, but not corrupt enough to steal the same credentials from any other source (inc. database access).

It is like letting a criminal into your home, then being concerned that they might see your security system's pin written on a sticky note on the fridge. Sure, it is a problem, but ultimately the criminal doesn't need that pin to steal your shit, you already let them walk right in.

[lukeschlather]

GET logs end up in all sorts of places. I would not be at all surprised if anyone working at EBay could get access to them. Not to say they should have access to them, but access to the logs is different from access to the server. Log reading permissions have a rightfully lower standard than ssh/deployment permissions.

(But part of what makes it OK to have more people with access to the logs is you don't put things like username/passwords for all of your customers in the logs.)

[brandonl222]

With that logic it doesn't make sense to store passwords encrypted in the DB then either. If an outside attacker gains access to a system it would really suck to have a bunch of passwords sitting in logs unencrypted. Security in depth and all...

[mfer]

Often times server logs are sent to other locations (such as central locations) for storage. This can be storage for compliance purposes. I wonder if these are logged and sent to some other location. They may be visible to a great many people who don't have direct server access.

In general don't log sensitive information because you don't know how those logs will be used.

[mschuster91]

Not exactly. In corp/uni environments there may very well be a SSL-stripping proxy - and it works because in a corp setting you have the fake ca cert installed by IT, and in uni you often have to accept a cert when first connecting to the uni VPN.

[lmm]

In that kind of environment all bets are off already and recovering security is hopeless, no?

[brown9-2]

In this scenario the distinction between GET and POST becomes irrelevant.

[mschuster91]

No, it does not, because usually an appliance will have some sort of logging - which will usually include the URL, which in turn contains the GET parameter.

[amalag]

If there is an inserted CA then I believe any cert from any website can be MITM'ed and there are appliances that do this.

From PaloAltoNetworks website:

"... firewall proxies outbound SSL connections by intercepting outbound SSL requests and generating a certificate on the fly for the site the user wants to visit."

[cmdrfred]

I'm writing a Html5/Js end to end encrypted chat app for just this scenario. It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin.

[drodgers]

"It won't stop a nation state modifying requests in transit and injecting their own js"

It should stop a nation state if you serve up the JS via HTTPS and use certificate pinning.

[icebraining]

Pinning doesn't work against the "corporate CA" scenario, at least if the user is using Chrome:

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

https://www.chromium.org/Home/chromium-security/security-faq...

[cmdrfred]

Thanks for that. I had no idea. I wish there was a way to grab the certificate in Js. Just so you could alert the user that they are MITMed. As it stands I will have to instruct them to check manually.

[lmm]

If they're MITMing they could replace whatever JS you put with something else, by definition.

[mschuster91]

You could use https://openpgpjs.org/ for example to provide in-browser cryptography between user and server.

[pingec]

Wait, what? So I guess our admin can read my gmail :/

Will pay attention to what certs are being served from now on...

[slashcrypto]

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