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. Also, the site is likely to be broken for user agents that do not support cookies. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
