Security concerns surrounding HTTP GET in Web Development

Question

I'm currently a developer making my first foray into web development, mostly using C# ASP.NET services such as MVC and Web API. Getting into the HTTP side of things, I'm currently deciding whether or not to be using POST or GET when accessing my data models.

Obviously, I would be using POST when my repository layer is communicating with data sources, but when surmising how my controller will be parsing input from the user (with this being a front-facing web app), I became unnerved thinking about passing somewhat sensitive information values over HTTP GET, seeing as they would be entered through the URL. Remembering in education how much the dangers of SQL injection were beat into us, I have an (unfounded) hunch that I should only be using POST when going to my repository that communicates with my databases.

Am I correct in assuming there are valid security concerns with using HTTP GET to send parameters to a repository layer that communicates with my databases?

Naturally, I would be enforcing validation on both ends, but it feels to me that GET has a broader range of attack than POST. I would like my validation to be narrow and strict.

Answer 1

• Over TLS (https) connections, both POST and GET data is encrypted, so there's no difference in that regard.
• To avoid SQL injection (or other) issues, you must validate and sanitize all incoming user input regardless of whether POST or GET was used.
• Inherently, using POST requests is not more secure, but it's good practice to use POST requests when submitting data that will change (for example) something in the database.

• If using GET, there's a bigger risk that your server logging tools will also log sensitive information by default (HTTP request log will contain all data). You can minimize this risk by submitting data with POST.

• Also, in some scenarios (depending on your specific usage and needs), having sensitive information in the URL as query parameters (for example /data/something?secret_key=123321) will also be stored in the browser history, and this might be a risk if shared computers are common for your users.

Answer 2

It sounds like you are conflating several different issues in security terms. There are some issues with using GET parameters, although these are not specifically related to SQL injection, and SQL injection cannot be prevented by only using POST requests.

Most of the concerns with GET requests result from indirect access to data: for example, GET parameters can be viewed in browser history, and are stored in server side log files without any additional processing. POST requests, on the other hand, are usually shown in browser history without any parameter values, and server logs usually don't include the body of the requests.

SQLi, on the other hand, results from using untrusted data in the context of a SQL query. It doesn't matter where the data comes from: GET request, POST request, other backend system, cookies, the database itself.

It is generally good practice to strictly enforce specific request methods, but that's more about avoiding other types of flaw (older versions of PHP would merge GET and POST variables, for example, resulting in problems where the intended values could be overwritten by supplying a client inserted parameter of the other type). One paradigm for this is following the REST methods (https://restfulapi.net/http-methods/) where each HTTP method maps to a type of action, so GET requests only retrieve data, POST requests create data, PUT requests update data, and DELETE requests delete data, but this doesn't always make sense for all applications (e.g. where making PUT/DELETE requests isn't possible for some reason).

Answer 3

To add to the over answers without too much overlap, the concern about URLs is not unfounded and there are specific recommendations for this: "In GET requests sensitive data should be transferred in an HTTP Header"

As noted in my comment on another answer anything done with GET needs to be idempotent and safe.

Answer 4

GET and POST (long with PUT, DELETE and PATCH) have very specific functional roles, redefining the semantics of these is not something to be taken without very careful consideration.

Even when using POST, if you are following the REST conventions, there is significant transactional information within the URL.

If you are running any sort of transactional content, or content which requires authentication then you must use HTTPS. This (mostly) addresses the confidentiality of data in transit. Your remaining issues are at the endpoints. Presumably serverside is not a concern. At the client, the data will persist in the history on the device but only for URLs which the user navigated to - XMLHttpRequests do not populate the history unless you explicitly put the data there.

Browsers are relatively good at partitioning the data belonging to seperate sites - but there are various channels which can leak information to a determined attacker but these are all (AFAIK) in the domain of static data - hostnames, certificates, HSTS status, content caching...browser history is not one of these.

So apart from the threat model of someone getting hold of a user's device and extracting the data from the filesystem, there is no difference between a GET and a POST from a security perspective.

Serverside, its common practice to log the entire URL - so you should afford similar protections to your log data as you do to the transactional data.