tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Help regarding CSRF Filter in Tomcat 7
Date Fri, 16 Nov 2012 20:29:03 GMT
Mark Thomas wrote:
> On 16/11/2012 18:50, André Warnier wrote:
>> Mark Thomas wrote:
>>> On 16/11/2012 16:12, André Warnier wrote:
>>>> Mark Thomas wrote:
>>>>> On 16/11/2012 10:01, André Warnier wrote:
>>>>>> Vijaya Kumar wrote:
>>>>>>> Hi, I work on a web application that is vulnerable to CSRF(Cross
Site
>>>>>>> Request Forgery) attack. Tomcat 7 has a CSRF prevention filter.
I
>>>>>>> went
>>>>>>> through the description to configure this filter. This filter
expects
>>>>>>> that we call HttpServletResponse#encodeRedirectURL(String) or
>>>>>>> HttpServletResponse#encodeURL(String). I see that in my
>>>>>>> application we
>>>>>>> don't use the above mentioned methods. Can you please let me
know
>>>>>>> whether there is any other way of using this filter without making
>>>>>>> calls to encodeURL() or encodeRedirectURL()?
>>>>>>> To be precise, I am looking for a way to incorporate CSRF Filter
>>>>>>> in an
>>>>>>> already existing application that doesn't use
>>>>>>> HttpServletResponse#encodeRedirectURL(String) or
>>>>>>> HttpServletResponse#encodeURL(String).
>>>>>>> Any help in this regard is appreciated.
>>>>>> Hi.
>>>>>> I am a bit of a novice in this area, but as far as I understand what
a
>>>>>> CSRF attack is
>>>>>> (http://en.wikipedia.org/wiki/Cross-site_request_forgery), and what
>>>>>> this
>>>>>> filter does, it seems to me at least that if your are not using
>>>>>> HttpServletResponse#encodeRedirectURL(String) or
>>>>>> HttpServletResponse#encodeURL(String) in your application, then this
>>>>>> filter would be unnecessary, and would not help anyway.
>>>>> Wrong.
>>>>>
>>>>> In order for the CSRF prevention filter to work, an application must
>>>>> run
>>>>> all URLs through encodeRedirectURL() or encodeURL(). If applications
>>>>> don't do this, the filter can't add the nonce to the URL that is
>>>>> used to
>>>>> provide the CSRF protection.
>>>>>
>>>> Well, that's essentially what I was saying. Or am I missing something
>>>> here ?
>>> Your statement that "if you are not using encodeRedirectURL() or
>>> encodeURL() in your application, then this filter would be unnecessary"
>>> is wrong. It implies that if you are not using those methods then you
>>> will not be at risk of a CSRF attack.
>> We're getting into semantics here. :-)
> 
> Exactly. Meaning is important. Particularly on a list where English is
> not the first language of many of the participants.
> 
>> I posit that I never implied what you say here.
> 
> On that, we disagree.
> 
>> Let's ask the question another way : if the OP is not using
>> encodeRedirectURL() or encodeURL() in his application, does the CSRF
>> prevention filter help in any way to prevent CSRF attacks on his
>> application ?
> 
> In that scenario, the CSRFPreventionFilter filter on its own will not
> help. 

Ok, so let's back up a little.

The OP wrote :

.."This filter expects that we call HttpServletResponse#encodeRedirectURL(String) or 
HttpServletResponse#encodeURL(String).
I see that in my application we don't use the above mentioned methods."
..

To which I answered :

.. "if your [sic, apologies] are not using HttpServletResponse#encodeRedirectURL(String) 
or HttpServletResponse#encodeURL(String) in your application, then this filter would be 
unnecessary"..

Notice the "if (condition) then { statement }" expression.

Did this contain any implication of the OP's application not being susceptible to CSRF 
attacks if he is not using these calls ?
Was my response incorrect ?
Or was the "Wrong." sentence maybe a bit hasty ?

English is not my native language either, but on this list I strive to express myself in 
it, in a logically and syntactically correct fashion.

I also suggested to the attention of the OP the tips provided on the same Wikipedia page,

to make CSRF attacks more difficult.  This would also seem to deny the implication that I

ever intended to tell the OP that his application was not susceptible to CSRF attacks. (*)

Also, the site is likely to be broken for user agents that do not
> support cookies.
> 

Point taken, but that was not the question.



(*) on purpose, semantically ;-)


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


Mime
View raw message