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