On Mon, Jul 2, 2012 at 1:28 PM, Jeff Williams <
jeff.williams_at_aspectsecurity.com> wrote:
> 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?
>
No. Feel free to share it with any interested parties.
>
> 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
>