Re: CSRF Protection: double submitted cookie
I've created a ticket and attached a reference implementation: https://issues.apache.org/jira/browse/WICKET-1885 Jörn On Mon, Oct 20, 2008 at 11:31 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: The double-submitted-cookie isn't related to double submit protection, no. Thats a completely different turf. With that out of the way, its enough to create just one cookie and use that both while rendering and validating forms. I hope that makes it clearer. I'll try to provide a reference implementation tomorrow. Jörn On Mon, Oct 20, 2008 at 12:58 PM, Johan Compagner [EMAIL PROTECTED] wrote: hmm i will read the paper then I stil dont get it how it is possible with 1 cookie, that then can never change when it is first generated and all the forms also just have that value right? But it is also for double submit protection right? So the cookie has to change right? But how can you then have 1 cookie? for all the forms? If i submit one and that is rerendered or redirected to another page. (so it has a new cookie so the double submit cant happen) But if a new cookie is set then all other forms are also suddenly invalid.. and that looks pretty wrong to me johan On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: No, the cookie is subject to the same-origin-policy, both in reading and writing. The request is authenticated because the session cookie is set, but its invalid when the form itself is missing the value. Combining the attack with XSS would give access to the cookie, but then he could just as well hijack the session directly. In other words: With CSRF alone there is no way for the attacker to read the cookie, therefore its enough to use just one. Their whitepaper may do a better job of explaining the techniquie: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Solutions are described on page 8ff. Jörn On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED] wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the
RE: CSRF Protection: double submitted cookie
I need to read more about this, but I am interested to know if there are any advantages to storing the token in a cookie for validation rather than putting it into the session. I suppose if statelessness is required then it is necessary. One advantage to storing it in session is that it does help prevent the double form submit error. See http://www.nabble.com/Double-submit-problem-td15957979.html#a15957979 for example. The JIRA issue you mention has a broken link. It looks like it should be http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks If I am not mistaken. -Original Message- From: Jörn Zaefferer [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 22, 2008 8:05 AM To: users@wicket.apache.org Subject: Re: CSRF Protection: double submitted cookie I've created a ticket and attached a reference implementation: https://issues.apache.org/jira/browse/WICKET-1885 Jörn On Mon, Oct 20, 2008 at 11:31 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: The double-submitted-cookie isn't related to double submit protection, no. Thats a completely different turf. With that out of the way, its enough to create just one cookie and use that both while rendering and validating forms. I hope that makes it clearer. I'll try to provide a reference implementation tomorrow. Jörn On Mon, Oct 20, 2008 at 12:58 PM, Johan Compagner [EMAIL PROTECTED] wrote: hmm i will read the paper then I stil dont get it how it is possible with 1 cookie, that then can never change when it is first generated and all the forms also just have that value right? But it is also for double submit protection right? So the cookie has to change right? But how can you then have 1 cookie? for all the forms? If i submit one and that is rerendered or redirected to another page. (so it has a new cookie so the double submit cant happen) But if a new cookie is set then all other forms are also suddenly invalid.. and that looks pretty wrong to me johan On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: No, the cookie is subject to the same-origin-policy, both in reading and writing. The request is authenticated because the session cookie is set, but its invalid when the form itself is missing the value. Combining the attack with XSS would give access to the cookie, but then he could just as well hijack the session directly. In other words: With CSRF alone there is no way for the attacker to read the cookie, therefore its enough to use just one. Their whitepaper may do a better job of explaining the techniquie: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Solutions are described on page 8ff. Jörn On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED] wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means
Re: CSRF Protection: double submitted cookie
for me +1 if it does not interfere with other stuff. Jörn Zaefferer wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CSRF Protection: double submitted cookie
what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn
Re: CSRF Protection: double submitted cookie
No, the cookie is subject to the same-origin-policy, both in reading and writing. The request is authenticated because the session cookie is set, but its invalid when the form itself is missing the value. Combining the attack with XSS would give access to the cookie, but then he could just as well hijack the session directly. In other words: With CSRF alone there is no way for the attacker to read the cookie, therefore its enough to use just one. Their whitepaper may do a better job of explaining the techniquie: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Solutions are described on page 8ff. Jörn On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED] wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn
Re: CSRF Protection: double submitted cookie
I've looked at CSRFGuard, the approach has several of the drawbacks described in the paper. Its much less effective then the double-submitted-cookie, eg. it involves buffering and rewriting the response to modify forms. It generates values for each rendered form and stores it in the user session (http://www.owasp.org/index.php/How_CSRFGuard_Works). The double-submitted-cookie doesn't require any serverstate at all. I'm not sure what happens when you open multiple tabs/windows, but considering that the value is stored in the session, it probably breaks. Again something the cookie pattern isn't affected by. Jörn On Mon, Oct 20, 2008 at 12:42 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: I found this interesting: Don't forget OWASP CSRFTester and CSRFGuard http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks#comment-100619 Comment by Jeff Williams http://www.owasp.org on September 29th, 2008 at 9:53 am. OWASP has made two tools available to help with CSRF problems. The first is CSRFTester which will allow you to test your website for CSRF problems. The tool allows you to create multi-step test cases and has been used to transfer funds, create accounts, issue checks, etc... The second tool is called CSRFGuard, and it's a Java EE filter that can be placed in front of an entire application to provide CSRF protection. CSRFGuard uses javascript to insert tokens into forms and links, and then validates the token in every request. You can find both free tools at http://www.owasp.org.; Especially the part about the filter. If it's compatible with wicket and a okay approach, I'd say forget about these things... Johan Compagner wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn -- -Wicket for love Nino
Re: CSRF Protection: double submitted cookie
hmm i will read the paper then I stil dont get it how it is possible with 1 cookie, that then can never change when it is first generated and all the forms also just have that value right? But it is also for double submit protection right? So the cookie has to change right? But how can you then have 1 cookie? for all the forms? If i submit one and that is rerendered or redirected to another page. (so it has a new cookie so the double submit cant happen) But if a new cookie is set then all other forms are also suddenly invalid.. and that looks pretty wrong to me johan On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: No, the cookie is subject to the same-origin-policy, both in reading and writing. The request is authenticated because the session cookie is set, but its invalid when the form itself is missing the value. Combining the attack with XSS would give access to the cookie, but then he could just as well hijack the session directly. In other words: With CSRF alone there is no way for the attacker to read the cookie, therefore its enough to use just one. Their whitepaper may do a better job of explaining the techniquie: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Solutions are described on page 8ff. Jörn On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED] wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn
Re: CSRF Protection: double submitted cookie
Ahh, a no go for their filter then. The idea are very nice though. Jörn Zaefferer wrote: I've looked at CSRFGuard, the approach has several of the drawbacks described in the paper. Its much less effective then the double-submitted-cookie, eg. it involves buffering and rewriting the response to modify forms. It generates values for each rendered form and stores it in the user session (http://www.owasp.org/index.php/How_CSRFGuard_Works). The double-submitted-cookie doesn't require any serverstate at all. I'm not sure what happens when you open multiple tabs/windows, but considering that the value is stored in the session, it probably breaks. Again something the cookie pattern isn't affected by. Jörn On Mon, Oct 20, 2008 at 12:42 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: I found this interesting: Don't forget OWASP CSRFTester and CSRFGuard http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks#comment-100619 Comment by Jeff Williams http://www.owasp.org on September 29th, 2008 at 9:53 am. OWASP has made two tools available to help with CSRF problems. The first is CSRFTester which will allow you to test your website for CSRF problems. The tool allows you to create multi-step test cases and has been used to transfer funds, create accounts, issue checks, etc... The second tool is called CSRFGuard, and it's a Java EE filter that can be placed in front of an entire application to provide CSRF protection. CSRFGuard uses javascript to insert tokens into forms and links, and then validates the token in every request. You can find both free tools at http://www.owasp.org.; Especially the part about the filter. If it's compatible with wicket and a okay approach, I'd say forget about these things... Johan Compagner wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn
Re: CSRF Protection: double submitted cookie
I found this interesting: Don't forget OWASP CSRFTester and CSRFGuard http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks#comment-100619 Comment by Jeff Williams http://www.owasp.org on September 29th, 2008 at 9:53 am. OWASP has made two tools available to help with CSRF problems. The first is CSRFTester which will allow you to test your website for CSRF problems. The tool allows you to create multi-step test cases and has been used to transfer funds, create accounts, issue checks, etc... The second tool is called CSRFGuard, and it's a Java EE filter that can be placed in front of an entire application to provide CSRF protection. CSRFGuard uses javascript to insert tokens into forms and links, and then validates the token in every request. You can find both free tools at http://www.owasp.org.; Especially the part about the filter. If it's compatible with wicket and a okay approach, I'd say forget about these things... Johan Compagner wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CSRF Protection: double submitted cookie
Hmm and what about nested forms? Johan Compagner wrote: hmm i will read the paper then I stil dont get it how it is possible with 1 cookie, that then can never change when it is first generated and all the forms also just have that value right? But it is also for double submit protection right? So the cookie has to change right? But how can you then have 1 cookie? for all the forms? If i submit one and that is rerendered or redirected to another page. (so it has a new cookie so the double submit cant happen) But if a new cookie is set then all other forms are also suddenly invalid.. and that looks pretty wrong to me johan On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: No, the cookie is subject to the same-origin-policy, both in reading and writing. The request is authenticated because the session cookie is set, but its invalid when the form itself is missing the value. Combining the attack with XSS would give access to the cookie, but then he could just as well hijack the session directly. In other words: With CSRF alone there is no way for the attacker to read the cookie, therefore its enough to use just one. Their whitepaper may do a better job of explaining the techniquie: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Solutions are described on page 8ff. Jörn On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED] wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]