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
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
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
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
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
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
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 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 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 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 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 ? 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. - 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
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é Warnier 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
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
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