On 13/09/2012 20:16, Jeff Williams wrote:
>> 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.
I'm not concerned about that. If a developer protects GET and not HEAD
then that is their responsibility. Given the definition of HEAD, I don't
see an issue with an implementation that calls doGet() in doHead().
> 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.
That is a problem with the JSP implementations, not the Servlet spec.
The JSP spec certainly suggests using service() rather than doXXX() but
it doesn't require it. Neither could I see any discussion of HTTP
methods in the JSP spec. It looks to be possible for JSP implementations
to respond to a subset of verbs (GET, HEAD, POST?) and reject the rest.
That list of verbs needs to be configurable. If this approach is viable,
then a useful addition to the JSP spec would be a way a defining which
verbs a JSP should respond to. Further discussion of this point really
belongs with the JSP EG.
I'm not sure of the current status of the JSP EG. Does anyone here know?
>> 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.
Excluding the JSP issue which is out of scope for the Servlet EG, the
developer has to do something to introduce support for the verb. Hence
my view that they need to take responsibility for that.
>> 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.
Then argue for clarifying the text and the examples, not for making the
rules even more complex.
>> 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.
This is supported in web.xml. Folks just have to use it.
We could remove support for the deny option although that won't be
backwards compatible so I suspect it will never happen.
In the meantime, use of deny could be strongly discouraged and
containers are free to log warnings if users use the deny rather than
allow approach.
> 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.
On that, we disagree.
Mark
>
> --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
>