4 ms·

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 wort

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.

slashcrypto 10y ago
you got a point, i will do a short edit here.
mschuster91 10y ago
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.
- cmdrfred 10y ago
  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 10y ago
    "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.
    - deleted 10y ago
      [deleted]
    - icebraining 10y ago
      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#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- https://www.chromium.org/Home/chromium-security/security-faq...
      - cmdrfred 10y ago
        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 10y ago
        If they're MITMing they could replace whatever JS you put with something else, by definition.
        ncallaway 10y ago
        While this is true, a parent comment from the user you're responding to has already explicitly mentioned this as a potential issue: "It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin."
        mschuster91 10y ago
        You could use https://openpgpjs.org/ https://openpgpjs.org/ for example to provide in-browser cryptography between user and server.
        cmdrfred 10y ago
        I've considered it but the overhead on the server side would be too much for the ad-free (ad's = loss of privacy IMO) and non-monetized vision I have. I use diffie-hellman to distribute an encrypted master key to each client that is used initially for the chat. I'm going to tell users not to consider that private (I can certainly man in the middle it from the server as I'm the one who generated the key) but they can use that key to discuss what private key they will use and then enter it manually (my brown dog's name + my birthday with only the first letter of my last name capitalized for example). In that master key I sent earlier there is also a salt to add to the hash of the password they select so even if the key they pick is weak it still might protect them. Everything is wrapped up in AES256 thanks to the Stanford Javascript Crypto Library. I may use openpgpjs down the line for private messages within rooms. I also want to experiment with WebRTC for private messages and maybe offer some opportunistic peer to peer connections but I haven't gotten the far yet.
- lmm 10y ago
  In that kind of environment all bets are off already and recovering security is hopeless, no?
- brown9-2 10y ago
  In this scenario the distinction between GET and POST becomes irrelevant.
  - mschuster91 10y ago
    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 10y ago
  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."
  - deleted 10y ago
    [deleted]
arviewer 10y ago
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 10y ago
  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 10y ago
    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 10y ago
    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 10y ago
  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.

slashcrypto 10y ago

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

mschuster91 10y ago

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.

cmdrfred 10y ago
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 10y ago
  "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.
  - deleted 10y ago
    [deleted]
  - icebraining 10y ago
    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#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- https://www.chromium.org/Home/chromium-security/security-faq...
    - cmdrfred 10y ago
      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 10y ago
        If they're MITMing they could replace whatever JS you put with something else, by definition.
        ncallaway 10y ago
        While this is true, a parent comment from the user you're responding to has already explicitly mentioned this as a potential issue: "It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin."
      - mschuster91 10y ago
        You could use https://openpgpjs.org/ https://openpgpjs.org/ for example to provide in-browser cryptography between user and server.
        cmdrfred 10y ago
        I've considered it but the overhead on the server side would be too much for the ad-free (ad's = loss of privacy IMO) and non-monetized vision I have. I use diffie-hellman to distribute an encrypted master key to each client that is used initially for the chat. I'm going to tell users not to consider that private (I can certainly man in the middle it from the server as I'm the one who generated the key) but they can use that key to discuss what private key they will use and then enter it manually (my brown dog's name + my birthday with only the first letter of my last name capitalized for example). In that master key I sent earlier there is also a salt to add to the hash of the password they select so even if the key they pick is weak it still might protect them. Everything is wrapped up in AES256 thanks to the Stanford Javascript Crypto Library. I may use openpgpjs down the line for private messages within rooms. I also want to experiment with WebRTC for private messages and maybe offer some opportunistic peer to peer connections but I haven't gotten the far yet.
lmm 10y ago
In that kind of environment all bets are off already and recovering security is hopeless, no?
brown9-2 10y ago
In this scenario the distinction between GET and POST becomes irrelevant.
- mschuster91 10y ago
  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 10y ago
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."
- deleted 10y ago
  [deleted]

arviewer 10y ago

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 10y ago
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 10y ago
  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 10y ago
  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 10y ago
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.