All,
I was disappointed to hear that work on the DENY semantic for uncovered
HTTP methods hadn't progressed. I thought it was done. Here's the
thread and I guess it just sort of died there.
http://java.net/projects/servlet-spec/lists/jsr340-experts/archive/2012-
03/message/7. 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.
After our (long) discussions, I came to recognize that Ron's proposal is
a masterful job of balancing all the competing concerns. The proposal
1) completely eliminates this class of vulnerabilities, 2) allows
existing apps to be protected with only a configuration change, and 3)
won't require much tweaking unless the application was already
vulnerable. I get that there are some things to be worked out with
annotations and fragments, but this is dangerous for folks to use and
reflects badly on the servlet spec.
Personally, I would rather cause some applications to break and have a
servlet spec that's secure out of the box. But if that's not possible,
then Ron's proposal seems right.
--Jeff