0

Apparently I was under the misconception that GET and POST methods differ in the sense that the query parameters are put in plaintext as a part of the URL in GET method and the query parameters are THERE IN THE URL IN ENCODED(ENCRYPTED) FORM .

However , I realize that this was a grave misconception . And after going through :

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9

and after writing a simple socket server in python and sending it both GET and POST (through form submission) and printing the request in server side

I got to know that only in GET the parameters are there in the URL but in POST the parameters are there in the request body .

I went through the following question as well so as to see if there is any difference in sending a GET and POST at lower level (C-Level) :

Simple C example of doing an HTTP POST and consuming the response

So as in the above question above I saw that there is no special encryption being applied to the POST request .

As such I would like to confirm the following :

1.The insecurities associated with GET and POST are only because of the GET method attaching the parameters in the URL .

For somebody who can have the whole request body , both the GET and POST methods are equally vulnerable .

  1. Over the network , both the GET and POST body are sent with the equal degree of encryption applied to them .

Looking forward to comments and explanations.

Erwin Kairos
  • 31
  • 1

1 Answers1

0

Yes. The server only gets to know about the URL the user entered/clicked on because it's sent as the data of the request, after (transport) security has been negotiated so it's not inherently insecure:

  • you type into a browser: https://myhost.com/a.page?param=value
  • browser does DNS lookup of myhost.com
  • browser connects to https port 443 of retrieved ip
  • browser negotiates security, possibly including myhost.com if the server is using SNI certificates

  • connection is now encrypted, browser sends request data over the link:

    GET /a.page?param=value HTTP/1.1 Host: my host.com (other headers)

    //Probably no body data

    ---- or ----

    POST /a.page HTTP/1.1 Host: my host.com (other headers)

    param=value //body data

You can see it's all just data sent over an encrypted connection, the headers and the body are separated by a blank line. A GET doesn't have to have a body but is not prevented from having one. A POST usually has a body, but the point I'm making is that the data sent (param=value) that is relevant to the request (the stuff the user typed in, potentially sensitive info) is included somewhere in the request - either in the headers or the body - but all of it is encrypted

The only real difference from a security perspective is that the browser history tends to retain the full URL and hence in the case of a GET request would show param=value in the history to the next person reading it. The data in transit is secure for either GET or POST, but the tendency to put sensitive data on a POST centres on the "data at rest" concept in the context of the client browser's history. If the browser kept no history (and the address bar didn't show the parameters to shoulder surfers) then either method would be approximately equivalent to the other

Securing the connection between browser and server is quite simple and then means the existing send/receive data facilities all work without individual attention, but it's by no means the only way of securing connection. It would be conceivably possibly not to have the transport do it but instead for the server to send a piece of JavaScript and a public part of a public/private key pair on the page somewhere, then every request the page [script causes the browser to] makes could have its data individually encrypted and even though an interim observer could see most of the request, the data could be secured that way. It is only decryptable by the server because the server retains the private part of the key pair

Caius Jard
  • 72,509
  • 5
  • 49
  • 80