On 10/07/2012 19:57, Jeff Williams wrote:
>>> 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.
A simple filter that checks there are not unexpected multiple values for
a given parameter should mitigate most of the risk.
Any API change is going to require the developers to change their code
so it is 50/50. Change your code to use the new API or change your code
to use different URLs.
The much bigger issue is getting developers to realise that they need to
change their code in the first place.
>> 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.
That is worthy of further consideration. If the default is changed,
there needs to a way to revert to the current approach because there
will be developers that have relied on it.
>>> 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.
As part of that discussion I think we should consider issuing a security
guide alongside the spec that explains the various issues and how to
avoid them.
Mark