Re: Help regarding CSRF Filter in Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 11/16/12 3:29 PM, André Warnier wrote: .. if your [sic, apologies] are not using HttpServletResponse#encodeRedirectURL(String) or HttpServletResponse#encodeURL(String) in your application, then this filter would be unnecessary.. I think if you replaced unnecessary with ineffective then you're closer to your intended meaning. To me, unnecessary implies that the application is safe and the filter would not add anything when the truth is that the application's safety is irrelevant and that adding the filter will not protect it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCoSLQACgkQ9CaO5/Lv0PBKYACgheqBq7b9N3R0Lz4H9I6DEKqy +0YAoJUaVckkX37Rfa8Xs0atMmRQ3v0U =DxZM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Help regarding CSRF Filter in Tomcat 7
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. Thanks, Vijay - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
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. Why are you saying that your application is vulnerable to CSRF ? (Note that the same Wikipedia page seems to provide various tips to make your application less vulnerable to CSRF attacks in general). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
Hi, Thanks a lot for the quick response. I have already gone through the suggestions given on Wikipedia. I found that the suggestions provided over there are not feasible in our application's context. Therefore, I am looking for an alternate way of preventing this attack. -Vijay André Warniera...@ice-sa.com 11/16/2012 3:31 PM 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. Why are you saying that your application is vulnerable to CSRF ? (Note that the same Wikipedia page seems to provide various tips to make your application less vulnerable to CSRF attacks in general). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
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. Note: That filter is very generic and works for simple applications (e.g. Tomcat's HTML Manager app) but is likely to be quite tricky to set up for complex applications. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
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. Use of those methods is required if the CSRFPreventionFilter is to work correctly. Use of those methods does not determine if an application has a problem in the first place. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
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. :-) I posit that I never implied what you say here. 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 ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
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
Re: Help regarding CSRF Filter in Tomcat 7
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
On 11/16/2012 3:29 PM, André Warnier wrote:
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 ?
I'm not Mark, but to me it *did* give that impression, since you said
unnecessary. IMO that implied that he wouldn't be vulnerable if he
wasn't using those calls (and therefore the filter wouldn't be needed).
If you had said something like would not help, or would not be
useful, then it would not have had the same implications.
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. (*)
Because of the way I interpreted your earlier statement, that suggestion
looked to me like suggesting additional reading to get a fuller
background explanation of the problem and its mitigations.
D
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
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).
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. That reinforces the idea that CSRF protection is not required.
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.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help regarding CSRF Filter in Tomcat 7
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
Re: Help regarding CSRF Filter in Tomcat 7
André, On 16/11/2012 14:39, André Warnier wrote: 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. filter is ineffective might work for you. - Bob
Re: Help regarding CSRF Filter in Tomcat 7
Bob Hall wrote: André, On 16/11/2012 14:39, André Warnier wrote: 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. filter is ineffective might work for you. - Bob That does sound better to me. Shall we agree that the correct phrasing should have been : If you are not using HttpServletResponse#encodeRedirectURL(String) or HttpServletResponse#encodeURL(String) in your application, then this filter would be ineffective (and wasteful of system resources) ..but your application can still be subjected to CSRF attacks. From the Oxford dictionary on-line : Definition of ineffective adjective . not producing any significant or desired effect: . the legal sanctions against oil spills are virtually ineffective . a weak and ineffective president Definition of useless adjective . not fulfilling or not expected to achieve the intended purpose or desired outcome: . a piece of useless knowledge . we tried to pacify him but it was useless . informal : having no ability or skill in a specified activity or area: he was useless at football Definition of unnecessary adjective . not needed: some people feel that holiday insurance is unnecessary . more than is needed; excessive: . good construction is essential to avoid unnecessary waste - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
