jsr340-experts@servlet-spec.java.net

[jsr340-experts] Re: [servlet-spec users] Re: security concern (protocol parameter parsing order)

From: Remy Maucherat <rmaucher_at_redhat.com>
Date: Wed, 11 Jul 2012 09:30:31 +0200

On Tue, 2012-07-10 at 10:16 -0700, Rajiv Mordani wrote:
> 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.

+1

> > 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.

I don't want to add tons of user level utilities that are pretty much
ever changing, and a nest of security issues (once protection is
claimed, any bug will be a security issue).

-- 
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc