On Sun, Jul 1, 2012 at 1:50 PM, Mark Thomas <markt_at_apache.org> wrote:
> 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.
>
Thanks for the feedback. I feel that we should let the API do the right
thing (i.e. the current behavior), and address security issues at a higher
level.
>
> Mark
>