Security implications of posting an HTTPS GET request with sensitive data

Are there any security implications to making an H开发者_StackOverflow中文版TTPS/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

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.

4. 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.
5. 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.

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.

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.