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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
