1

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 communing 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'd like my validation to be narrow and strict.

  • What relation do you make between GET vs. POST and SQL injection? – curiousguy Jul 21 '18 at 22:22
7
  • 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.

  • Thank you for your concise answer and the concerns I should be looking for. – nostalgk Jul 18 '18 at 13:20
  • Not only is it good practice to use POST requests when changing the database, GET requests (and HEAD, OPTIONS, TRACE, PUT, and DELETE) must be idempotent. Unfortunately non-idempotent GET requests are sadly common. Non-idempotent GET requests means SameSite=lax session cookies don't fully prevent CSRF. – AndrolGenhald Jul 18 '18 at 15:25
  • @AndrolGenhald GET is not just required to be idempotent: '..GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe"' Since browsers and email clients will GET img tags immediately without user input, doing anything not considered 'safe' with a GET is inherently a vulnerability. – JimmyJames Jul 18 '18 at 20:46
  • @JimmyJames Can you be logged into a website with your email client? How is IMG in that context a vulnerability beyond sending an "email was opened" message back? – curiousguy Jul 21 '18 at 22:25
  • 1
    @curiousguy I did a quick search on "simple machine forums vulnerabilities" and coincidentally the first item in the CVE database is "...allows remote attackers to hijack the authentication of administrators or moderators via vectors involving image files..." It seems the original source for this is down/gone but perhaps the secret value was the hack they used to address the problem. The RFC is pretty clear: "...GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval." Ignore this at your own peril. – JimmyJames Jul 23 '18 at 17:07
1

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).

  • Thank you, this is very relevant to what I'm looking for and I appreciate you pointing out where I was conflating different issues. – nostalgk Jul 18 '18 at 13:19
0

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.

0

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.

  • owasp.org/index.php/… – JimmyJames Jul 18 '18 at 21:09
  • If you are referring to "In GET requests sensitive data should be transferred in an HTTP Header", I can profile you from the unencrypted DNS requests your computer sends: From the route and speed with which you move through a website: From the way you type data into my application. All data is sensitive. – symcbean Jul 18 '18 at 21:32
  • I'm just referring you to the OWASP recommendations. The assumption is that we are using HTTPS here. If you aren't then, yes, this doesn't matter. The reason is in the text: "Passwords, security tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable." – JimmyJames Jul 19 '18 at 13:36
  • (sigh.........) – symcbean Jul 20 '18 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.