3

I have developed myself in the last few months about web development in java (servlets and jsp). I am developing a web server, which is mainly serving for an application. Actually it is running on google app engine. My concern is, although I am using SSL connections, sending parameters in the URL (e.g. https://www.xyz.com/server?password=1234&username=uname) may not be secure. Should I use another way or is it really secure? I don't know if this url is delivered as plaint text as whole (with the parameters)?

Any help would be appreciated!

Genom
  • 207
  • 1
  • 12
  • Thanks a lot. You made everything clear. I suppose Google-App-Engine stores the URLs in logs but I need to check I am not sure. – Genom Sep 26 '11 at 09:15

4 Answers4

6

Your problem seems to go further than Web Server and Google App Engine.

Sending a password through a web form to your server is a very common security issue. See this SO threads:

Community
  • 1
  • 1
JMax
  • 26,109
  • 12
  • 69
  • 88
6

Everything is encrypted, including the URL and its parameters. You might still avoid them because they might be stored in server-side logs and in the browser history, though.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • And sent to others in the Referer as long as the target site uses HTTPS too (at least according to the [RFC](http://tools.ietf.org/html/rfc2616#section-15.1.3); not sure about actual implementations) – Roman Starkov Apr 17 '12 at 17:40
  • Back in 2003, I had to fix a recruiting firms web app because a customer found their username and password in their portfolio site Apache logs. The user was linking to his portfolio web site from his record in the system. So yeah, if the REFERRER value is sent, all query params are visible in other web servers that log that info. Both sites were using HTTPS. Don't put secrets in URLs :) – Ryan J. McDonough Aug 10 '16 at 11:02
2

The complete HTTP request including the request line is encrypted inside SSL.

Example http request for the above URL which will all be contained within the SSL tunnel:

GET /server?password=1234&username=uname HTTP/1.1
Host: www.xyz.com
...

It is possible though that your application will log the requested URL, as this contains the users password this may not be OK.

krock
  • 28,904
  • 13
  • 79
  • 85
2

Well, apart from the issues to do with logging and visibility of URLs (i.e., what happens before and after the secure communication) both GET and POST are equally secure; there is very little information that is exchanged before the encrypted channel is established, not even the first line of the HTTP protocol. But that doesn't mean you should use GET for this.

The issue is that logging in is changing the state of the server and should not be repeated without the user getting properly notified that this is happening (to prevent surprises with Javascript). The state that is being changed is of the user session information on the server, because what logging in does is associate a verified identity with that session. Because it is a (significant) change of state, the operation should not be done by GET; while you could do it by PUT technically, POST is better because of the non-idempotency assumptions associated with it (which in turn encourages browsers to pop up a warning dialog).

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • 1
    To be clear, I mean that while there are minor security reasons to prefer POST (the choice of operation not being of major importance, which it would have been if the URL was communicated in the clear) there's also a deeper reason for going with POST. It'd be the right thing to do _even without the encryption._ – Donal Fellows Sep 26 '11 at 08:35