SSL with GET and POST

Question

I'm pretty new to security, so forgive my basic question, but does SSL encrypt POST requests but not GET requests?

For instance, if I have two requests

GET: www.mycoolsite.com/index?id=1&type=xyz

POST

site: www.mycoolsite.com/index { Params: id=1&type=xyz }

Is it safe to assume that someone is able to intercept the whole GET request (reading id and type), but if they intercept the POST they will be able to see the site path, but because it is going over SSL, they cannot see the params of id and type?

No, the full _HTTP_ communication is encapsulated in _SSL/TLS_, **if the protocol is _HTTPS_ for both examples!** Be aware that referenced resources _(images, etc.)_ may be delivered insecure, depending on their uri. — ordag, Mar 08 '12 at 19:32
Just wanted to point out that if you're using GETs to pass credentials (regardless if you're using SSL) that the passwords will be stored in plain text in the Web server logs. — k1DBLITZ, Jul 11 '13 at 13:55

score 62 · Accepted Answer · edited Feb 18 '17 at 16:10

Now, the question is, do you know what a HTTP request looks like?

Well, assuming not, here's an example of one:

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

All of this information is enscapulated within the SSL transport - as the comment on your answer kindly says. This means:

Get parameters are encrypted.
HTTP Body (post parameters) are encrypted.

What's not necessarily secure:

The host you're asking for. Most web servers these days support Host: something parameters so multiple domains can be handled by one web server on one interface and IP address. Clearly, this header is encrypted, however, if you run non-https traffic to the site it should be clear which hosts you might connect to. Even if that's not the case, reverse DNS will certainly tell you what's hosted on that IP and you can probably make a reasonable guess from there.
Your browser/client information. Unfortunately each https client is different and its negotiation process might potentially give away what platform it runs on, or what browser it is. This is not the end of the world by any means, it's just a fact to understand.

POST requests look similar to get requests, except they contain a body. This may look like this:

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

There are some more complicated variants, of course, but essentially it is all encrypted anyway.

All of the answers here were very good. In fact, it was hard to pic the "best" answer as each was complimentary of the other. The reason I choose this one is because it showed what a get and post looks like. However, I really like that Gilles went into other things to watch out for, and the same goes for Dr Jimbob's answer. In fact, Ordag's comment was something I didn't even consider before, so I'm thankful for that as well. If I could, i would aggregate all the answers and mark all of them as the accepted answer as each builds upon the last. — TomJ, Mar 09 '12 at 16:36
To add a detail, the browser makes the destination host visible through the [Server Name Indication (SNI)](http://en.wikipedia.org/wiki/Server_Name_Indication) extension of TLS. — mavam, Mar 29 '12 at 16:54

dr jimbob · Answer 2 · 2012-03-08T20:56:00.910

41

I didn't see this mentioned in the other responses, but you generally should not put secret information (passwords) in GET requests even with SSL, but use POST instead. Why? The URL with the sensitive information will generally be logged at both ends; e.g., in your browsers history list (https://www.example.com?user=me&password=MyPassword) as well as the logs on the server. POST information (especially with passwords) is generally not written to webserver logs, though obviously can be configured to be logged--so its best not to reuse (or use similar) passwords at different sites.

edited Mar 08 '12 at 20:56

answered Mar 08 '12 at 20:08

dr jimbob

38,768
8
92
161

This [answer mentions that the referer may contain sensitive information](http://stackoverflow.com/a/26672275/819887) as well. In this [newsthead](http://answers.google.com/answers/threadview/id/758002.html#comments) it is stated, that sensitive information is stripped of. These leaves me confused; could the referer contain sensitive information? Is this still the case even for a get request from javascript using ajax in a single page application? – surfmuggle Nov 03 '14 at 10:24
@threeFourOneSixOneThree - It is possible for sites to strip sensitive information via javascript. However, by default (at least with all the browsers that I've tested), the referer header includes all HTTP GET query parameters. I've created a link on reddit to whatismyreferer.com (which echos the referer information that websites commonly log). Go to this link with GET parameters at the end like: https://www.reddit.com/r/sandboxtest/comments/2l7adf/referer_test/?username=dumb&password=leaked and you will find the sensitive parts are part of the referer header (even with https). – dr jimbob Nov 03 '14 at 22:38

score 21 · Answer 3 · edited Mar 17 '17 at 13:14

SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL. A GET is just as well protected as a POST.

When SSL works as intended, an eavesdropper can only see what IP address is connecting to what IP address (and on what port, but it's usually 443), at what time, and how much. If there are multiple virtual hosts on the same machine, the attacker cannot know which one you are contacting (however, the eavesdropper may see your DNS requests just before the HTTPS request and take a plausible guess). All this information is also authenticated: an active attacker cannot play man-in-the-middle and modify the data in transit.

Things that can make SSL not work as intended:

Application misuse, where some data is accidentally sent over plain HTTP.
One of the rare vulnerabilities in the SSL protocol, such as the recent BEAST vulnerability.
Bad certificate manipulation, which allows the attacker to pass off as the server, either because the server's certificate has been leaked, a certification authority has improperly delivered a certificate to the attacker, or because the client does not check the server's certificate correctly.
- On this note, remember that SSL, as it is used most of the time, authenticates the server but not the client. The server cannot assume anything about the client.
A side channel attack may reveal some information to the eavesdropper. For example, the exact timing at which the participants send data may reveal something about how the data is computed and thus about the nature of the data. The size of each packet is also known to the attacker. How revealing this can be depends on whether the participants take precaution and on the nature of the information. A real-time conversation is a lot more prone to such traffic analysis than the download of a file.

See also How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it? for some background.

score 6 · Answer 4 · answered Mar 15 '12 at 11:16

Just to add one more small detail, as to how this is accomplished over HTTP.
You're probably wondering (or you should be, if you know are familiar with the SSL handshake), how the SSL channel is created, without the GET request being sent unencrypted? What about if my request has to go through a proxy - how is that possible?

HTTP v1.1 introduced a CONNECT HTTP Method, which basically sends a simplified request to the server through a proxy, containing only the simplest host URL (without any additional parameters, headers, or body). Based on this request, a SSL tunnel is constructed, and then the original GET (or POST) request is sent over it.

score 5 · Answer 5 · answered Jan 16 '14 at 15:34

Another point not mentioned is that if you use GET and have any embedded or linked third party content (site ads for example) then that third party site will get the full URL (with sensitive parameter data) in the Referer header.

That exposes the data to third parties who shouldn't have it.

score 4 · Answer 6 · edited May 23 '17 at 12:40

Source: Answer on Stack Overflow

The GET method is meant for data retrieval only and should not have any side-effects. But POST is meant for that specific purpose: altering data on the server side.

GET requests can easily be foreged (see Cross-Site Request Forgery) by just placing an image on a page while forging POST requests is not that easy (this is also a reason why you should only allow authorized POST requests).

SSL with GET and POST

6 Answers6

Linked

Related