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
-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
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
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:
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
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
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
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
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
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
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
11 matches
Mail list logo
