I'm not sure that changing the API to provide a mechanism to avoid
this issue would work well. Frameworks would have to be updated to
support only 3.1 API and I cannot see that happening for many years.
Developers would also need to be aware that they should do this and
once aware, it is far simpler for them to change the form or to update
their framework with checks for multi-valued returns.
In short, I don't see that asking developers to use the "correct" API
will be any more affective than asking them to specify the forms
target.
cheers
On 2 July 2012 23:31, Wenbo Zhu <wenbozhu_at_gmail.com> wrote:
>
>
> 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
>
>
--
Greg Wilkins <gregw_at_intalio.com>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.