> For "verb tampering" to be an issue an application/framework has to do
the following:
> 1) Override one of the service() methods of the default HttpServlet
and add support for the new verb.
> 2) Implement that verb by calling one of the other doXXX methods.
> 3) Protect the XXX verb with a security constraint but leave the new
verb unprotected.
> Regarding 1), the Javadoc makes it very clear that this is almost
certainly a bad idea.
Unfortunately, there's a certain amount of overlap between the verbs.
To implement the HEAD request the container will execute a GET and then
strip off the HTTP response body that was generated. This confuses the
issue of which methods to "allow" as an attacker can now send a HEAD to
bypass the constraint.
For new verbs, the Javadoc is also, unfortunately, irrelevant because
JSPs respond to any verb. Many JSPs have interesting business logic in
them (unfortunately), and others disclose valuable information. That
makes it easy to bypass any security-constraints that include methods.
> Regarding 2), one has to ask why on earth the new verb was introduced
in the first place.
A developer probably wouldn't, but an attacker certainly would. That's
why we called it tampering.
> Regarding 3), given the hoops a developer as to jump through and the
warnings they
> have to have ignored to reach this point then responsibility for
failing to secure the
> result properly lies squarely with the developer.
I just don't see any real blocks to making a security mistake with this.
The only possibility is that they read and understand the spec, which is
demonstrably confusing.
> I am strongly against making any changes to the Servlet specification.
> The previous EGs have done more than enough to make clear the dangers
of this approach.
> If application/framework developers insist on ignoring that advice
then they have to take responsibility.
As I've mentioned, I would strongly prefer the approach where the
methods listed are the only ones allowed. I believe that makes sense
and is what developers expect. However, I think Ron's proposal is
better than leaving in place the confusing AND insecure approach in the
current spec.
--Jeff
-----Original Message-----
From: Mark Thomas [mailto:markt_at_apache.org]
Sent: Thursday, September 13, 2012 2:35 PM
To: jsr340-experts_at_servlet-spec.java.net
Cc: Jeff Williams
Subject: Re: [servlet-spec users] [jsr340-experts] Verb tampering Was:
Digest for list jsr340-experts_at_servlet-spec.java.net
On 11/09/2012 03:14, Jeff Williams wrote:
> The paper about verb tampering and why you should care is here.
> https://www.aspectsecurity.com/wp-content/plugins/download-monitor/dow
> nl
> oad.php?id=18.
>
> For those who just want a quick summary, verb tampering is a big deal.
> In our security testing, we have used it to force access to critical
> administrative functionality. Literally the only thing protecting
> these functions is the secrecy of the URL, which is frequently
> guessable or brute forceable. To access a "protected" JSP, all the
> attacker has to do is change the verb to JEFF. To invoke a "protected"
> servlet, they can just send a HEAD request. For example, at attacker
> could forge a request to a bank admin page to change a user's
> password, then drain their bank account.
>
> To me, leaving this unfixed is unthinkable. My initial suggestion to
> Ron was to change to a default deny semantic. But he eventually
> convinced me that the expert group would never go for it because it
> would likely break many apps. Leaving this a documentation issue
> simply ensures that many applications will remain vulnerable.
This is absolutely not a issue for the Servlet specification. It may be
an issue for an implementation but I would be very surprised if any of
the implementations have done something sufficiently stupid for this to
be an problem.
The default HttpServlet implementation has a separate method for each
HTTP verb.
The default implementation of every single one of those methods is to
return a 405 response to HTTP/1.1 requests and 400 for HTTP/1.0 and
HTTP/0.9 requests.
Unrecognised HTTP verbs receive a 501 response.
For "verb tampering" to be an issue an application/framework has to do
the following:
1) Override one of the service() methods of the default HttpServlet and
add support for the new verb.
2) Implement that verb by calling one of the other doXXX methods.
3) Protect the XXX verb with a security constraint but leave the new
verb unprotected.
Regarding 1), the Javadoc makes it very clear that this is almost
certainly a bad idea.
Regarding 2), one has to ask why on earth the new verb was introduced in
the first place.
Regarding 3), given the hoops a developer as to jump through and the
warnings they have to have ignored to reach this point then
responsibility for failing to secure the result properly lies squarely
with the developer.
I am strongly against making any changes to the Servlet specification.
The previous EGs have done more than enough to make clear the dangers of
this approach. If application/framework developers insist on ignoring
that advice then they have to take responsibility.
Mark