Hi Jeff,
See comments in-line -
On 7/5/12 5:03 PM, Jeff Williams wrote:
> Hi,
>
> 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). 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.
> 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.
- Rajiv
> --Jeff
>
>
> -----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.