securityauthenticationsslhttpssapui5

Are security concerns sending a password using a GET request over https valid?

We have webpage which uses the -framework to build a . The communication between the browser and the server uses . The interaction to log into the page is the following:

  1. The user opens the website by entering https://myserver.com in the browser
  2. A login dialogue with two form fields for unsername and password is shown.
  3. After entering username and password and pressing the login-button
  4. an ajax-request is send using GET to the URL: https://myusername:myPassword@myserver.com/foo/bar/metadata

According to my understanding using GET to send sensitive data is never a good idea. But this answer to HTTPS is the url string secure says the following

HTTPS Establishes an underlying SSL conenction before any HTTP data is
transferred. This ensures that all URL data (with the exception of
hostname, which is used to establish the connection) is carried solely
within this encrypted connection and is protected from
man-in-the-middle attacks in the same way that any HTTPS data is.

An in another answer in the same thread:

These fields [for example form field, query strings] are stripped off
of the URL when creating the routing information in the https packaging 
process by the browser and are included in the encrypted data block.

The page data (form, text, and query string) are passed in the
encrypted block after the encryption methods are determined and the
handshake completes.

But it seems that there still might be security concerns using :

Is this the case for URLs like?

    https://myusername:myPassword@myserver.com/foo/bar/metadata
    // or 
    https://myserver.com/?user=myUsername&pass=MyPasswort

Additional questions on this topic:

On security.stackexchange are additional informations:

But in my opinion a few aspects are still not answered

Question

In my opinion, these are valid objections against using get. Is it a bad idea to use get to send passwords?

Are these the attack vectors, are there others?

What are the attack vectors when sending sensitive data (password) over https using get?

Thanks

Solution

  • These two approaches are fundamentally different:

    myusername:myPassword@ is the "User Information" (this form is actually deprecated in the latest URI RFC), whereas ?user=myUsername&pass=MyPasswort is part of the query.

    If you look at this example from RFC 3986:

         foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     / \ /                        \
     urn:example:animal:ferret:nose

    myusername:myPassword@ is part of the authority. In practice, use HTTP (Basic) authentication headers will generally be used to convey this information. On the server side, headers are generally not logged (and if they are, whether the client entered them into their location bar or via an input dialog would make no difference). In general (although it's implementation dependent), browsers don't store it in the location bar, or at least they remove the password. It appears that Firefox keeps the userinfo in the browser history, while Chrome doesn't (and IE doesn't really support them without workaround)

    In contrast, ?user=myUsername&pass=MyPasswort is the query, a much more integral part of the URI, and it is send as the HTTP Request-URI. This will be in the browser's history and the server's logs. This will also be passed in the referrer.

    To put it simply, myusername:myPassword@ is clearly designed to convey information that is potentially sensitive, and browsers are generally designed to handle this appropriately, whereas browsers can't guess which part of which queries are sensitive and which are not: expect information leakage there.

    The referrer information will also generally not leak to third parties, since the Referer header coming from an HTTPS page is normally only sent with other request on HTTPS to the same host. (Of course, if you have used https://myserver.com/?user=myUsername&pass=MyPasswort, this will be in the logs of that same host, but you're not making it much worth since it stays on the same server logs.)

    This is specified in the HTTP specification (Section 15.1.3):

    Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

    Although it is just a "SHOULD NOT", Internet Explorer, Chrome and Firefox seem to implement it this way. Whether this applies to HTTPS requests from one host to another depends on the browser and its version.

    It is now possible to override this behaviour, as described in this question and this draft specification, using a <meta> header, but you wouldn't do that on a sensitive page that uses ?user=myUsername&pass=MyPasswort anyway.

    Note that the rest of HTTP specification (Section 15.1.3) is also relevant:

    Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead

    Using ?user=myUsername&pass=MyPasswort is exactly like using a GET based form and, while the Referer issue can be contained, the problems regarding logs and history remain.