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/downl
> 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