1

Other than over your shoulder peeping, if a password is sent using GET in plaintext over an encrypted connection, are there any extra security disadvantages or is it the same as POST?

Anders
  • 64,406
  • 24
  • 178
  • 215
Crizly
  • 2,597
  • 4
  • 18
  • 29
  • I'm not sure if this is really a duplicate. The linked question is marked as a duplicate of a question which asks if GET parameters are encrypted when using HTTPS. This question seems to be more about sending confidential data via GET. But it does seem to be a duplicate of [Using GET to submit username/password?](https://security.stackexchange.com/questions/43470/using-get-to-submit-username-password) – tim Jun 30 '16 at 20:33

1 Answers1

7

No confidential data should ever be sent via GET.

The data may be leaked or stored by:

  • referers if you link to a different page after a login
  • your server logs which is an issue if these logs are ever available, for example via LFI, wrong server configurations, backups, etc.
  • browser histories which is an issue if multiple people use the same browser - eg in companies or in public libraries -, or even by other websites if history sniffing is an option.
  • proxy servers that can decrypt the requests
  • users sharing links

The CWE for this issue would be CWE-598.

tim
  • 29,018
  • 7
  • 95
  • 119
  • 1
    Great answer! I would like to add that some frameworks don't do CSRF checks on GET requests. That would open up the webapp to login CSRF. – Anders Jun 30 '16 at 20:22
  • @Anders very good point. And frameworks have a good reason not to do CSRF checks on GET requests. If a CSRF check would be performed, the CSRF token may be leaked as well, which is why all requests that change state should be POST. – tim Jun 30 '16 at 20:26