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
