TL;DR:

Is there a valid reason to demand a software vendor to stop using HTTP PUT and DELETE methods in a web application and use only GET and POST? The application uses frameworks to whitelist allowed request paths and methods.

In other words, is there any difference from the security standpoint in allowing the deletion of a record via either DELETE or POST methods without changing the code and security checks in it?

Full question

Our customer configured their Tomcat instance with the following, according to their corporate standard:

<security-constraint> 

    <web-resource-collection> 

        <web-resource-name>restricted methods</web-resource-name> 

        <url-pattern>/*</url-pattern> 

        <http-method>CONNECT</http-method> 

        <http-method>PUT</http-method> 

        <http-method>DELETE</http-method> 

        <http-method>OPTIONS</http-method> 

        <http-method>TRACE</http-method> 

    </web-resource-collection> 

    <user-data-constraint> 

        <transport-guarantee>CONFIDENTIAL</transport-guarantee> 

    </user-data-constraint> 

    <auth-constraint /> 

</security-constraint> 

This, among the Http Header Security Filter configuration, made our application break.

Our application provides the same HTTP Header security features in Spring Security. Also, our application is RESTful, so we widely use PUT and DELETE methods for file upload. In future releases, we are also planning to use websockets (but from a search, they don't use CONNECT, which is for proxying).

Our customer said that they will have to raise a policy exception in production in order remove the offending lines from Tomcat configuration and make the application work.

The security exception policy is triggered when vendor applications do not comply with security requirement in a way that 1) fixing the issue cannot be done within the schedules and 2) no evident vulnerability is found. Exception policies require senior management approval.

However, security policy exceptions require our customer to engage the vendor within 6 months in "fixing the security issue". Within 6 months, vendor has to provide costs and deadlines to meet the security policy.

This means that they will return to me asking for a quotation to make the application work with enabled HTTP method filtering and HTTP Header Security filter.

I don't want to do them a favour and change all Ajax calls from RESTful patterns to GET/POST only, not even for money if possible. I would like instead to prove that their security implementation is not only incompatible, but redundant, with regards to the security implementations within the application.

If we set a precedent in doing this customer a favour with PUT and DELETE requests, we will have to face requests like "be compatible with my framework/policy/environment" from a large customer base (all banks and financial institutions). In the future, that may turn against our cost management.

Question is, as in the TLDR, could using PUT and DELETE methods alone, regardless of the security features of the application, pose a security risk?

If proven that the sole HTTP verb does not pose a security risk, I will be able to raise a permanent exception policy and confront the IT staff with solid argumentation.

Edit

I work in a software factory that deploys the same product instance to a large number of customers and our cloud. We are fully using all the tools we have on board, including the REST pattern. We are planning to employ HATEOAS, WebSockets, resumable file downloads, and everything the web technology can offer us to deliver better experience. Yes, sounds like a marketing line. Anyway, security is still a concern in our products.

I suspect this is a case of someone zealously applying "best practices" that they don't understand.

HTTP Verb Tampering Attack

The reason this best practice exists is because of the HTTP Verb Tampering Attack. From this article:

Many Web server authentication mechanisms use verb-based authentication and access controls. For example, an administrator can configure a Web server to allow unrestricted access to a Web page using HTTP GET requests, but restrict POSTs to administrators only. However, many implementations of verb-based security mechanisms enforce the security rules in an unsecure manner, allowing access to restricted resources by using alternative HTTP methods (such as HEAD) or even arbitrary character strings.

So someone decided that because some apps are badly-written, all apps should be banned from accepting HTTP verbs other than GET or POST, because ... you know ... mumble mumble SECURITY!!

My opinion (possibly incomplete / incorrect, please post comments) :

• Pure HTML / CSS / js content should be restricted to GET and POST because these are the only verbs allowed in the HTML spec.


• APIs (AJAX, REST) should be allowed to use any verb from the HTTP spec, that said:
  
  
  
  
  • Be aware that even if your application-layer correctly enforces verb-based access controls, your webserver front-end may not, so you owe it to your customers to do some security testing and make sure your app enforces proper authentication and access controls on all verbs that you support. I recommend following the OWASP testing guide.
  
  
  
  

It sounds like your app is fine and your customer has an overly-zealous security policy.

As an aside, HEAD is an interesting example; some security scanners seem to complain if your app responds to HEAD requests, because some apps will return valid headers without invoking the proper auth checks. However, most properly designed apps will process a full GET and then only return the headers, including the correct content-length:. So for apps using modern frameworks, there is probably no way to bypass auth logic on your GET controller. Do some quick tests though!
(Thanks @usr-local-ΕΨΗΕΛΩΝ for pointing this out in comments. See this Stack Overflow post for detail on how Spring MVC handles this.)

Arguably, DELETE and PUT are safer than GET/POST because they cannot be used in CSRF attacks. Also arguably, DELETE and PUT should be protected against CSRF anyway, because it is bad to base your application's security on the assumption that every browser implementation out there follows the standards. But it's not uncommon for applications to not have that protection, so maybe that's the thinking behind the ban, although I'm reaching here a bit.

Or maybe they just disabled all methods they did not need (which is a good practice) and over time that turned from a default into an unviolable rule.

I recommend engaging your corporate legal team soon, in order to have someone focusing on the business aspects of the discussions to come.

As part of the security exception policy, our customer's staff is obligated to engage the vendor in "fixing the security issue" within 6 months.

This means that they will return to me asking to make the application work with enabled HTTP method filtering and HTTP Header Security filter.

I don't want to do them a favour and change all Ajax calls from RESTful patterns to GET/POST only, not even for money.

Your client is obviously running their own bureaucracy, enforcing an inflexible policy. You believe you have three possible paths:

1. Convince them to change their policy.


2. Make the undesirable change.


3. Risk losing them as a customer.

Even though it appears to you to be a logical, technical decision, getting policies changed requires a fair amount of political wrangling. The person you are dealing with on the other side of the discussion may or may not have the standing in his company needed to successfully make such a request. He may not want to waste his time fighting his own bureaucracy for the change. His life might be considerably easier if he changes vendors and uses someone else’s product that already complies with their policies. Worse for you, his boss’ life will almost certainly be easier if he just changes vendors.

It would be irresponsible of you to think that you can succeed at getting them to change their policy without doing some serious planning for the other outcomes.

Good customers are hard enough to come by. You owe it to your company to carefully weigh the risk of losing one over this.