3

Are there any security implications to making an HTTPS/SSL GET operation with sensitive data in the URL? Would this be logged in cleartext in the IIS logs? Could network traffic requests be sniffed on an open WiFi access point?

i.e. https://www.websiteurl.com/get.aspx?user=user&password=password

Jonas
  • 121,568
  • 97
  • 310
  • 388
Kyle B.
  • 5,737
  • 6
  • 39
  • 57
  • possible duplicate of [Are https URLs encrypted?](http://stackoverflow.com/questions/499591/are-https-urls-encrypted) – NotMe Feb 28 '13 at 15:20

3 Answers3

5

Question is better answered here: Are https URLs encrypted?

  1. The URL is encrypted.
  2. However, the clear text may very well show up in the logs of the destination server as servers will unencrypt it and, depending on settings, store the values in the logs.
  3. The only part that would be sniffable is the dns portion. In this case www.websiteurl.com

That said you are better off not using get requests with the username/pw on the querystring anyway.

edit I wanted to add a bit more to this.

  1. The full unencrypted URL of a GET request is available in the browser history. If something is able to sniff the browser history then it would have complete access to whatever was in the query string.
  2. HTTP Referrer issues. The URL can be submitted to a third site if the user clicks a link that directs them to the other site.

Between #2 and #4, using the query string for sensitive data is unwise.

Community
  • 1
  • 1
NotMe
  • 87,343
  • 27
  • 171
  • 245
  • I tend to agree with Chris Loer's answer that the URL IS encrypted through SSL, however that there are other considerations for not doing it (or am I missing something?). – Claude Feb 27 '13 at 20:04
  • @Claude: I like Chris Loer's answer too. For the simple reason that mine was clearly wrong. The DNS portion of the lookup isn't encrypted, everything else on that line is. This question is a dupe of one from 2009 anyway. I'd delete this, but it was the accepted answer and I'm prevented from doing that. Instead, I'll just change the answer itself. – NotMe Feb 28 '13 at 15:22
3

HTTPS is HTTP on top of SSL/TLS. That means the entire contents of the HTTP interaction, including the URL, are encrypted. Only network-level information such as the IP address and port of the server is unencrypted. See HTTPS on wikipedia.

However, at the same time, this is only network-level security -- whatever web server is receiving the request will decrypt it (and maybe leave it in logs) before passing it on to any hosted web application. If you choose to use Basic Authentication, HTTPS protects the most obvious concern (sending the password in plaintext), but it has some other issues.

You mention that this is data being exchanged between two systems, which I take to mean that you're implementing the client side of the connection. In that case, regardless of how you send the data (GET/POST/headers/etc.), you need to be extra careful about validating the SSL certificate of the machine you're connecting to. Encrypting the sensitive data doesn't help you at all if a man-in-the-middle can get you to encrypt the data against his keys instead of against the keys of the server you trust. This is a huge source of vulnerabilities.

Community
  • 1
  • 1
Chris Loer
  • 190
  • 1
  • 12
1

The same what I wrote here holds. Not a good idea, browsers cache URLs, susceptible to social engineering, it appears in the server logs...

Use POST or Basic Authentication instead.

Community
  • 1
  • 1
emboss
  • 38,880
  • 7
  • 101
  • 108
  • This wouldn't be susceptible to social engineering as it is being used to exchange data between two systems. No bookmarking, caching, or anything of that nature would be applicable. Server logs are a concern, however, so point noted. – Kyle B. Aug 03 '11 at 15:09