API Design
Relative security factor of HTTP POST vs. GET
Side Effects of HTTP GET & POST
HTTP Logging on Servers
HTTP Referer:
Proxy Caching of HTTP GET requests
Showing information in the Web browser
Confused Deputy Attack
Cross-Site Scripting Attack
Conclusion
Introduction
Hi Readers! After a go through my previous articles, now we’ll discuss on difference between HTTP GET and HTTP POST method for the purpose of read-only or query-based operations in REST APIs.
Hope you must know about long-standing restriction on the utilization of GET requests for utilization in local apps. This case was found before general use of REST APIs and traditional web apps (server-side produced HTML). The only issue was no one truly knew or kept in memory why it wasn’t permitted - as it was “insecure”.
Let’s have discussion on Get vs. Post.
API Design
First, we must know the reason of using a GET request in a particular RESTful API. The entire point of an is to is to be capable for exchanging information through the native protocol of the WWW as it was meant to be utilized — HTTP v1.1 or HTTP v2for our objective.
This architectural approach is applied in the ‘Roy Fielding PhD dissertation’ in the year 2000. That dissertation does not discuss particularly while one HTTP approach or another should be utilized. Nor, does it particularly describe CRUD operations. However, the details of time of utilization of method over another are remained to the HTTP spec, “the WWW language.”
Hence, REST API design needs to attract inspiration from various sources and least pragmatism — and skip the religion. This includes the subset of current HTTP operations that apply traditional CRUD abilities (Create, Read, Edit, Delete); this is basically POST, PUT, GET, and DELETE. Though, it need not have to be this approach. Maybe we substitute PUT by PATCH. Probably, DELETE isn’t utilized and is basically an extra update that PUT/PATCH could focus on.
If I followed all the pseudo-rules I’ve listened over the years about which can and cannot be utilized as portion of REST APIs, there would be few HTTP 1.1 spec remained that could truly be utilized — which is type of silly. Some developers state that a true REST API can only utilize a 201-return code for POST calls.
Relative security factor of HTTP POST vs. GET
I’ve been in some organizations that have applied a global, heavy-handed, restriction of the utilization of GET requests for API-type link or even traditional web app. The reasons cited are basically something along the lines of:
The data will be viewed in the address bar of a web browser and noted in the history of web browser.
GET is not more secure than POST while transformed over the wire.
The URL along with query parameters are logged on the server.
If HTTPS (TLS v1.2 or advanced) is being utilized, neither GET nor POST request parameters can be viewed over the wire. On the other hand, an HTTP access log doesn’t need to store information on query parameters or, if you desired to be truly fancy, don’t allow sensitive values.
Afterall, these points will be valid, but lesser intrusive solutions can be applied to resolve potential issues. Applying powerful policies like restricting the utilization of GET requests in apps without conducting a completed threat assessment quantities to security theater (which refers, it may not help very much from a security posture).
Often these queries center around PII, HIPAA, or same type specifications. Basically, placing this type of information directly into the query parameter should be avoided. Some kind of abstraction should be applied to the design that could be utilized to reference based information indirectly— considering some procedures like tokenization for PCI information.
Generally, it is strongly suggested to perform within the thought of what these approaches are supposed to indicate. There is some gray area and space for dogma/religion to enter into it — recommended to avoid the same.
Accordingly, CRUD method explained above + OPTIONS approach (CORS) is the formula that has been utilized in almost each REST API I’ve design. The errors to that were found by minor compromises with users that have fallen into the critical traps explained in this blog post.
Side Effects of HTTP GET & POST
GET requests need to be utilized to obtain information while designing REST APIs; POST requests need to be utilized to create information while designing REST APIs. Making something is considered to be a side effect — if not that point.
The HTTP GET approach is not to possess side effects. It can be read-only for obtaining information. It is basically considered a wrong practice to apply any kind of write utility (the things that will possess side effects) in an HTTP GET. Although, there isn’t truly anything restricting a developer from performing this.
The suggestion here is to skip unintended behavior by making some kind of “write” functionality in a specific GET request. Save the same for the HTTP POST operations. This is a sequence where utilizing POST is suggested from the very description of the spec over GET. This is applicable to both traditional web apps and REST APIs.
HTTP Logging on Servers
If your app is logging sensitive values any way, just STOP IT now! This contains the general HTTP access log which most of the web server technologies have empowered. This is not good practice and one that common auditing and application to ideal practices should be capable to mitigate.
No need to disable all production logging. The shops can either disable all production logging of web servers and app servers completely or can disable the HTTP access log. This might be impossible to conduct forensic analysis or after-error trouble shooting organized on a system that has possessed all apps and disabled middleware logging.
The objective must be to filter out to start with the logging of parameters which are sensitive or might carry sensitive value. As per the product being utilized, this could either be easier or impossible. I would consider the capacities required here to be part of the technical need for any type of products though, most organizations aren’t considering that holistically while selecting products.
HTTP Referer:
HTTP requests produced by a web browser will generally include a request header named Referer. This contains the URL of the web page that produced it. If sensitive data is being carried through a request request URL, probably, the same URL could finish up in upcoming request Referer headers. A POST request won’t have this issue.
Nevertheless, for the AJAX, REST API calls from a web browser, the Referer header will have the JavaScript file’s URL that began the
request. This isn’t becoming specially interesting. For a system-to-system API call, the most likely won’t even be a Referer header. So, in most API-related cases, this isn’t becoming an issue.
Proxy Caching of HTTP GET requests
The comments raised in the last section regarding which organization owns the proxy are narrated here. If a proxy cannot be classified as trusted, steps need to be taken to skip it.
Where we have viewed reply caching was on something like a CDN in the front side of API Gateway or developed into an API Gateway. Turning this characteristic on, was generally accomplished with particular intent that has made sense for the API replies being captured. When utilized, it adheres to the HTTP directives referring how long something needs to be captured and whether it needs to be captured.
There is also the difference of caching according to HTTP Header, complete path, query parameters, etc. This can be changed widely.
In theory, you could get the reply of any HTTP approach, but rarely this makes reason for writing operations. If it was mandatory to cache something, tending to apply capturing of API requests (read-only) which covered in POSTs might be challenging (it could be accomplished with certainly completely characterized products, but it would cause nonsensical situations). This would be a specific reason to utilize GET for read-only API calls except POST.
This section applies to common web apps and REST APIs. For the specific REST APIs, answer caching doesn’t occur that often, but it happens sometimes.
Showing information in the Web browser
It is true, you can view GET requests with appropriate query parameters in the address bar and web Browser History. You can also view the whole contents of POST, PUT, and other HTTP approaches in web browser Developer Tools. One could often remove the history; though, this generally needs the permission or cooperation of the end user.
Confused Deputy Attack
According to Wikipedia, a Confused Deputy “is known as a legitimate, highly privileged computer app which is tricked by other program into utilizing its authority wrongly on the system. It is a particular kind of privilege escalation.” However, if the web browser is taken as the deputy in this act, both GET and POST requests could be included in a ‘confused deputy attack’.
Cross-Site Scripting Attack
XSS (Cross-Site Scripting) attacks trick a user (or more correctly the user’s web browser) into displaying an arbitrary script (generally JavaScript). This generally happens when unfiltered user data (input) is granted to be utilized in replies sent back to other users like a discussion forum. The unfiltered input could carry executable JavaScript which conducts an unnecessary action. This matter is discussed shortly here.
This kind of vulnerability can influence both GETs and POSTs. The mitigation plans can run across both ‘GET & POST’ requests.
This is a serious concern for genuine web apps and REST APIs, but most likely is going to need the utilization of a web browser for the API Consumer.
Conclusion
Overall, we have realized from the above that both post and get have equal importance in various situations. It’s very real that there are some considered situations where the utilization of a POST request has advantages of security over a GET request except the extra precautions, but also, in some situations where both are equally harmful to common attack vectors. It is critical that best-performances and resolution approaches for common vulnerabilities could be designed into all web apps. Those small advantages the POST request have not justified rejecting a GET request from our API design tool belt.
Post A Comment:
0 comments: