> All,
> 
> I'm playing with the CsrfPreventionFilter and things are working well
> in the following situations:
> 
> <a href="url">link text</a>
> 
> and
> 
> <form method="post" action="url">
> ...
> </form>
> 
> As long as the URL has been passed through request.encodeURL().
> 
> However, this one is causing me a problem:
> 
> <form method="GET" action="url">
> ...
> </form>
> 
> This builds a form like this:
> 
> <form method="GET"
> action="https://host/path?org.apache.catalina.filters.CSRF_NONCE=[...]";>
> ...
> </form>
> 
> Neither Firefox nor Chrome will send the query string present in a
> <form> action attribute if the method="GET". The method must be "POST"
> in order for this to be sent. This is due to the HTML standard[1].

The spec assumes that the action attribute doesn't already have a query
string. A strict reading of that text would lead to a request of:

GET /path?<nonce>?<form-attributes>

which is clearly wrong. Is there an actual (security?) problem the
browsers are trying to solve here or is this just a case of how they
have decided to interpret the HTML standard?

> Short of changing all <form> methods to "POST", is there any way
> around this?
> 
> I have read the code for CsrfPreventionFilter and it does not appear
> that the nonce if stored anywhere except in the CsrfResponseWrapper
> for the request (and the session's nonce cache, but that isn't
> request-specific).
> 
> Would it be inappropriate to add the CSRF_NONCE to the request
> attributes so that application code could use it directly if
> necessary? Something like this:
> 
> <form method="get" action="url">
>   ...
>   <input type="hidden" name="org.apache.catalina.filters.CSRF_NONCE"
> value="<%= request.getAttribute("CSRF_NONCE") %>" />
> </form>

I can't see any reason why not.

You could also add a "getYougest()" method the the nonce cache and then
look that up via the session since the nonce doesn't have to the one
generated for the current request.

Your approach looks cleaner though - and less dependent on the
implementation of the CsrfPreventionFilter.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to