>> Feedback from the OWASP community is that developers absolutely will
>> not get this right without some support from the API. I suggested
the
>> possibility of an optional method or parameter, like getParameter(
>> "foo", POST_ONLY ). Alternatively, I thought perhaps there might be
a
>> way to make POST the default (configurable?).
>
> I don't think we should change the API to handle this. This will still
> require the developers and frameworks to make sure that they use
> the right api (like Greg pointed out).
So if the API doesn't change, what exactly what are developers supposed
to do? Rewrite their app so that the form and form-handler are
different URLs? That seems extremely painful.
> As for making POST default
> doesn't make sense to me. In general you would always start with
> a "GET" to get the form before doing a post.
Just to clarify, I mean changing the spec so that parameters from the
body have precedence over parameters in the URL. That way, the attacker
will have a more difficult time overriding parameters that the user
provided. I think the developer's intent is almost certainly for the
form fields to override the URL, instead of the other way around.
>> I got several responses saying that an optional parameter would be
>> ignored, accomplishing nothing. Others suggested providing only
>> getURLParameter and getPostParameter methods. Of course we could
>> ignore the problem, and tell developers they need to avoid
self-posting forms.
>> But I think that would be an unfortunate outcome.
>>
>> At some point, the servlet team is going to have to start providing
>> support to developers for protecting against web attacks. At least
if
>> we want people to use it for critical apps. XSS, CSRF, header
>> injection, HPP, Clickjacking, HSTS, open redirect/forward,
>> sidejacking, URL rewriting, etc... they're all relatively easy to fix
>> but nobody does.
>>
>> How about something that helps developers manage all the
>> security-critical headers that have come out (X-Frame-Options,
>> X-XSS-Protection, X-Download-Options, Strict-Transport-Security,
>> etc...)
>>
>> In my opinion, these protections should be on by default and the
>> configuration should make it clear that other choices are dangerous.
>> I'm ready to help designing these protections if there's interest.
>
> We can start a thread on this topic and see what the EG thinks about
this.
Great!
--Jeff
> - Rajiv
>
> -----Original Message-----
> From: Greg Wilkins [mailto:gregw_at_intalio.com]
> Sent: Tuesday, July 03, 2012 4:21 AM
> To:jsr340-experts_at_servlet-spec.java.net
> Cc: Jeff Williams;tommyc_at_google.com
> Subject: Re: [jsr340-experts] Re: security concern (protocol parameter
> parsing order)
>
> 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.