Hi,
Some initial feedback on this making Java EE HPP-resistant....
I gather this happens when the form doesn't have a target set, so it
posts to the same URL it came from. This is a legacy pattern, but we
still see it quite frequently (just last week as a matter of fact). I
suppose it could also happen if the application uses the attacker's link
as the target attribute in the form, but that's pretty unlikely and
already a form of unchecked redirect vulnerability.
This technique *could* bypass a properly implemented CSRF token if GET
requests are not covered, which they frequently aren't. Many sites
don't protect their GET requests because they think they're idempotent
(like getting a form, for example). Most of their sensitive
transactions are POST anyway. So a HPP CSRF attack could work against
a site with a token if these conditions are met.
I would really like to see better support for protecting applications
against all forms of CSRF in Java EE. There should be an easy way to
specify that a set of URLs is considered public or bookmarkable.
Everything else should require a token.
I'll make sure to get feedback from the OWASP leaders. Are there any
restrictions on sharing Tommy's paper?
Thanks,
--Jeff
-----Original Message-----
From: Mark Thomas [mailto:markt_at_apache.org]
Sent: Sunday, July 01, 2012 4:51 PM
To: jsr340-experts_at_servlet-spec.java.net
Cc: Wenbo Zhu; tommyc_at_google.com
Subject: [jsr340-experts] Re: security concern (protocol parameter
parsing order)
On 30/06/2012 06:13, Wenbo Zhu wrote:
> Page 23, Section 3.1
>
> "
> Data from the query string and the post body are aggregated into the
> request parameter set. Query string data is presented before post body
> data.
> "
>
> Attached is a short write-up from Tommy (cc'ed) on the underlying
> security issue.
>
> Comments?
Short version:
- Interesting discovery. I don't recall seeing this elsewhere.
- It makes CSRF easier in some cases
- Standard CSRF protection is not by-passed by this technique
- We could modify the Servlet API to make mitigation simpler
- I'm on the fence as to whether we should change the API
Long version:
I don't recall having seen this before. Having reviewed the paper, it
looks like a variation of CSRF to me. The technique makes the
modification of POST requests easier, but only in the limited
circumstances where a FORM is POST'd to the same URL it was requested
from. A quick look at a couple of frameworks - Struts and Spring -
suggests that this is unlikely to be the standard configuration for most
sites.
It would be worth highlighting this is other security folks - OWASP in
particular come to mind - to see if there is anything else that needs to
be taken into consideration when assessing this technique.
Standard CSRF protection adds a nonce to each response that is returned
as part of the next request. Because the technique described in this
paper relies on the attacker crafting a URL for the victim to click, the
target site should reject the request since the request will not contain
the nonce. There is, of course, the assumption here that any site worth
attacking will have CSRF protection. If it doesn't this technique will
make a CSRF attack easier.
In terms of what we could do to mitigate attacks that use this
technique, we could add new getParameter() methods that return
parameters just from the request body and just from the query string
and/or we could add a method that returned a value but throws an
exception if there is not a unique value for that parameter. These
methods would make it simpler for developers to ensure they only process
the data they intend to process.
Given that standard CSRF protection is not bypassed by this attack I do
not see a pressing need for API changes in response. Arguably, some new
getParameter() methods could add some defence in depth but I'm not
convinced the benefits justify the effort. I have a very slight leaning
towards not adding these methods but am prepared to be convinced
otherwise.
Mark