FYI
---------- Forwarded message ----------
From: Tommy <tommyc_at_google.com>
Date: Thu, Jul 19, 2012 at 8:15 PM
Subject: Fwd: [servlet-spec users] [jsr340-experts] Re: security concern
(protocol parameter parsing order)
To: Wenbo Zhu <wenboz_at_google.com>
[Apologies for the late response; it turns out that I'm unable to post to
the list, so only immediate authors have been getting my replies.]
Note that the vulnerability is not limited to cases where developers fail
to specify a form action; it's also a problem when they are
indiscriminately forwarding query parameters or when a javascript XHR posts
to document.location. That seems like a lot of things that every developer
has to be on the lookout for, especially when it could be fixed without any
intervention on their part.
At the most basic level, it feels broken that it's not possible to
distinguish a user's form input from query string input using the
HttpServletRequest#getParameter API. Since there are a number of avenues
for the attack, and it's really easy for folks to get wrong if they're not
actively considering it, it seems to me like an API change would be
appropriate.
I like the idea of being able to opt out of the fixed behavior for folks
who may break, since people who are ambivalent will benefit and those who
are broken will realize it and work to fix it.
In the long run I'd prefer to see getQueryParameter/getBodyParameter
introduced and getParameter deprecated to eliminate the confusion. It'd
also be good to raise awareness on the issue, since the only documentation
of this behavior that I found was in the servlet spec (rather than, say,
javadoc on HttpServletReqeust).
On Wed, Jul 11, 2012 at 6:03 AM, Jeff Williams <
jeff.williams_at_aspectsecurity.com> wrote:
> >On 10 July 2012 20:57, Jeff Williams <jeff.williams_at_aspectsecurity.com>
> wrote:
> >> 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.
> >
> > All developers need to do is to specify the form handling URL and not
> let it
> > default to the page URL. The URL can be specified to be exactly the
> form URL
> > or something different, so the structure of the webapp does not need
> to change.
>
> That's a good point. I'll make sure that the OWASP guidance is updated
> to address this.
>
> > If any action should be taken, perhaps it should be suggested to the
> W3C that
> > HTTP spec be changed so that default form targets should not include
> the query
> > parameters?
>
> Hmm.... there's some fault on both sides here, and I'd hate to see this
> linger in a spec-finger-pointing war while people are vulnerable. I've
> asked OWASP to look into gathering some numbers to see how widespread
> this problem is.
>
> I was really hoping that there was something more we could do to make
> legacy apps safe. What about changing the default behavior to use POST
> parameters first? There could be an override configuration in web.xml
> if you want the current behavior.
>
> --Jeff
>