tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Help regarding CSRF Filter in Tomcat 7
Date Fri, 16 Nov 2012 22:39:12 GMT
Mark Thomas wrote:
> On 16/11/2012 20:29, André Warnier wrote:
>> 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.
> I did.
>> Did this contain any implication of the OP's application not being
>> susceptible to CSRF attacks if he is not using these calls ?
> Yes. You used the word "unnecessary" (i.e. the filter is not required;
> there is no need to use the filter in this case) when what you meant was
> "useless" (the filter won't work).

Response (to Mark and David) : I accept the verdict of the native English-speakers.
In my defense, I would say that to me, the word "useless" has more of a negative 
connotation than what I wanted to express.  Using an expression such as "the filter is 
useless" here may have suggested that I thought that this code was not worth the memory 
cells it was written on.  Which is of course far from my thoughts on the matter.
"Unnecessary" was a way for me to express that in these particular circumstances, it would

1) not help, while 2) - being a filter - adding unwarranted (?) overhead to the application.

> The use of "unnecessary" implied that the use of the filter was only
> necessary when using encodeRedirectURL() or encodeURL(). That in turn
> implies that CSRF only happens if encodeRedirectURL() or encodeURL() is
> used. That is what I responded to as wrong.
> What you were trying to say was something along the lines of:
> "If your application doesn't use encodeRedirectURL() or encodeURL() then
> the CSRF prevention filter isn't going to be able to help you as the
> correct operation of that filter requires that those methods are used."
>> Was my response incorrect ?
> Yes.
>> Or was the "Wrong." sentence maybe a bit hasty ?
> No.
>> 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.
> +1. As a native English speaker who struggles with foreign languages I
> am constantly in awe of those who are fluent in multiple languages such
> as yourself, as I know how hard I would have to work to get remotely
> close to that skill level. But we all make mistakes - me included (most
> of the evidence for that is in the archive of the dev list). In this
> case the choice of the word "unnecessary" was not the best choice as the
> primary meaning of the word is not what you intended.
>> 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. (*)
> You did, but after suggesting that their application may not be
> vulnerable to CRSF (see above) and querying why they thought that it
> was. 

Well, that was another poor expression of my intent then.  I was really trying to ask the

OP why he thought that his application was susceptible to CSRF attacks, not trying to cast

doubts on the matter.  That was after reading the Wikipedia article, and wondering how, 
with a real-world Tomcat-based application, someone might on the one hand have a valid 
session in that Tomcat-based application, yet be at the same time with another page open 
from another website containing a link or a reference to this very same Tomcat application

and being able to make use of it.  To my naive understanding, that combination of 
circumstances sounded relatively unlikely in the first place.
Of course I should have realised that if the OP had real concerns about this, he probably

wasn't going to expand on it on this public forum anyway.  But in the heat of the action,

my thinking didn't go that far.

> That reinforces the idea that CSRF protection is not required.

I recant, fully and wholeheartedly.

> The tips on Wikipedia are definitely worth the OP reading. I'd also
> recommend the OWASP materials on this topic (and web application
> security in general). They have a number of tools that can help
> including, if I recall correctly, a CSRF protection filter that is more
> powerful than the Tomcat one.
>> Also, the site is likely to be broken for user agents that do not
>>> support cookies.
>> Point taken, but that was not the question.
> Indeed. That was meant as a useful aside for folks reading this in the
> archives.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message