Re: CSRF Protection: double submitted cookie

2008-10-22 Thread Jörn Zaefferer
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

2008-10-22 Thread Zappaterrini, Larry
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

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

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

2008-10-20 Thread Johan Compagner
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

2008-10-20 Thread Jörn Zaefferer
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

2008-10-20 Thread Jörn Zaefferer
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

2008-10-20 Thread Johan Compagner
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

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

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

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

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

2008-10-20 Thread Nino Saturnino Martinez Vazquez Wael

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]