Page 1 of 2
CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 12:46 pm
by kaisellgren
Hi guys.
I've been thinking about this. Usually websites protect from CSRF attacks by either having a CAPTCHA or using tokens. Tokens are usually carried along with POST or GET. Instead, would it be a good idea to use cookies? Not really, but a funny experiment though. Cookies are available in all web browsers basically. If the cookies are compromised, that does not matter since we are protecting from CSRF attacks here.
Theory:
- if post or get is not empty
-- check that a token in cookies matches the db token
--- if not, redirect to main page
--- otherwise, continue
- create a token
- insert the token into the db and into the user cookies
EDIT: I'm not in need of a protection, I'm just wondering and trying to create alternative approaches. So please stick with the cookie approach, don't offer GET/POST approaches.
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 6:45 pm
by André D
Cookies are not a good place to store anti-CSRF tokens.
The URL and hidden form fields are good candidates for transmitting these tokens because a third-party site cannot get the victim's browser to make a valid request unless it knows the token's value. If you use cookies, the third-party, malicious site does not need to know the value of the token, because the victim's browser will send it automatically with any request for a site that matches the cookie's domain.
http://shiflett.org/articles/cross-site ... -forgeries
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 6:49 pm
by kaisellgren
André D wrote:If you use cookies, the third-party, malicious site does not need to know the value of the token, because the victim's browser will send it automatically with any request for a site that matches the cookie's domain.
No not necessarily. The victim must first go to the site and login to get the cookie created. And since it changes between every reload, an attacker does not know it.
The only problem I can think of is that if the user logs in and goes to some page and then goes to elsewhere while keeping the page open he might lead into problems. But the cookies are also per action specific though.
Basically only this type of attack succeeds:
- victim logs in.
- cookies is created.
- victim goes to attackers site.
- attackers site makes a CSRF attack on the site, and targets the very specific page that was open and to the very specific action (form).
That's the only problem here. I could either solve it with a time based renewel of token, or with HTTP referrer or with a JS that changes it whenever user leaves the page (window focus lost).
My current idea is to make a JS that will change the token whenever the user loses the focus of the site. Then it switches it back when the user has the focus again. So if he opens the admin page and opens a new tab or a window and goes to an attacker's site the attack wont work because the CSRF does not happen in the orginal window
EDIT: My current system works seamlessly

tried CSRF with GET and POST did not work. I'm using JS now.
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:01 pm
by Eran
What Andre is saying is correct. Cookie values are the source of XSS attacks, in which an attacking site uses the user's client to send requests to another server, which will authenticate the client if the user is currently logged in (with authentication results stored in a cookie) - allowing the offending site to interact with the server as if it were a logged in user.
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:08 pm
by André D
kaisellgren wrote:The victim must first go to the site and login to get the cookie created.
This is the nature of a CSRF attack. The attacker is exploiting the trust that a site has for an authenticated user.
kaisellgren wrote:since it changes between every reload, an attacker does not know it.
You're right that the attacker doesn't know the token's value, but he doesn't need to know it if you put it in a cookie. As I said before, the victim's browser will provide it.
If you change the token on each request, you may have limited the token's lifetime, but that isn't an effective barrier to attack for CSRF. Follow this:
1. The victim visits your site and gets a valid anti-CSRF token.
2. The victim visits a second page on your site, and you change the token.
3. The victim visits the attacker's site, which directs the browser to the attack URL on your site. Because the victim's browser had a valid token stored in a cookie (the one from step 2), the attack was successful.
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:11 pm
by kaisellgren
pytrin wrote:What Andre is saying is correct. Cookie values are the source of XSS attacks, in which an attacking site uses the user's client to send requests to another server, which will authenticate the client if the user is currently logged in (with authentication results stored in a cookie) - allowing the offending site to interact with the server as if it were a logged in user.
Your English is hard to understand, but aren't you talking about CSRF?
No XSS, no access to cookies. Even if you would, that's not going to help. The session is tied to the IP. Unless you are using the same network like wlan or so.
André D wrote:As I said before, the victim's browser will provide it.
It will, but it provides an incorrect value since it was changed by JS.
André D wrote:If you change the token on each request, you may have limited the token's lifetime, but that isn't an effective barrier to attack for CSRF. Follow this:
1. The victim visits your site and gets a valid anti-CSRF token.
2. The victim visits a second page on your site, and you change the token.
3. The victim visits the attacker's site, which directs the browser to the attack URL on your site. Because the victim's browser had a valid token stored in a cookie (the one from step 2), the attack was successful.
All correct except number 3. The value in the cookie is invalid if the user ever leaves the site. Loses the focus on the window.
Any other suggestions

Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:14 pm
by André D
Do not rely on JavaScript to do such a thing. What if the user has JavaScript disabled?
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:15 pm
by kaisellgren
André D wrote:Do not rely on JavaScript to do such a thing. What if the user has JavaScript disabled?
I don't really care. I'm just doing this for fun.
Btw. I found a way to crack it.
I made an evil page that counts to 10 with JS then submits a CSRF with POST.
Now if the victim logs in, switches to evil, and switches back in 10 seconds the attack will work.
Hmm, I have to rethink my strategy.
If I can proof that CSRF is protectable without using GET or POST, I will get $200.
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:23 pm
by Eran
Your English is hard to understand, but aren't you talking about CSRF?
What exactly about my English is hard to understand..
Sorry, I meant CSRF not XSS.
Basically, a compromised site runs malicious scripts (javascripts) as an unsuspecting user visits it. Those scripts usually involve requests to other sites in which the visiting user is currently logged in (via a cookie). As those requests are made from the user's client they will have the user's full privileges on any site he is logged in to. As Andre succinctly put it, those requests would also validate against your tokens, which are also stored in the cookies and are sent with the headers of the request.
Not sure how you intend to control the cookie from the client side, maybe using something like onBeforeUnload which is unreliable. In any case, you are leaving yourself open to more attacks which is not a good idea...
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:26 pm
by kaisellgren
pytrin wrote:Your English is hard to understand, but aren't you talking about CSRF?
What exactly about my English is hard to understand..
Sorry, I meant CSRF not XSS.
Basically, a compromised site runs malicious scripts (javascripts) as an unsuspecting user visits it. Those scripts usually involve requests to other sites in which the visiting user is currently logged in (via a cookie). As those requests are made from the user's client they will have the user's full privileges on any site he is logged in to. As Andre succinctly put it, those requests would also validate against your tokens, which are also stored in the cookies and are sent with the headers of the request.
Not sure how you intend to control the cookie from the client side, maybe using something like onBeforeUnload which is unreliable. In any case, you are leaving yourself open to more attacks which is not a good idea...
Yea I know the principles of CSRF.
If I can prove that I cna protect from CSRF without using GET or POST I get $200.
Anything. Anything. Maybe using Java could help me here? Hmm..
The focus thing did not work that great. I already explained above that if you make a little JS counter in the attacker page and then do a JS POST then it will work.
Btw, I think it's the lack of dots and commas that made your English hard to understand.
Anyway I'm going to sleep. Hopefully I get an idea while sleeping.
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:30 pm
by Eran
I counted 2 commas, one dot and one dash... but I guess it was a little congested.
Did you consider flash cookies?
http://www.imasuper.com/66/technology/f ... cy-killer/
Re: CSRF Tokens In Cookies.
Posted: Mon Feb 02, 2009 7:37 pm
by kaisellgren
Thanks, I'll have a look at them!
Re: CSRF Tokens In Cookies.
Posted: Tue Feb 03, 2009 1:19 am
by Mordred
Kai, you were already given multiple answers why it wouldn't work, and yet you persist

(All for a bet, eh!

)
Whatever solution you concoct with non get/post tokens, bear in mind that these - including javascript, java applets, flash, activeX are
optional. You must not rely on them, and therefore any solution based on them is moot.
Re: CSRF Tokens In Cookies.
Posted: Tue Feb 03, 2009 2:48 am
by aschlosberg
Even without the victim first having visited the site like you outlined a CSRF attack could still be perpetrated by first opening an iframe to the cookie generating page.
Re: CSRF Tokens In Cookies.
Posted: Tue Feb 03, 2009 7:20 am
by kaisellgren
Mordred wrote:Whatever solution you concoct with non get/post tokens, bear in mind that these - including javascript, java applets, flash, activeX are optional. You must not rely on them, and therefore any solution based on them is moot.
I know it's practically stupid to protect from CSRF without placing a token into GET/POST, but I still got 21 hours until deadline...
aschlosberg wrote:Even without the victim first having visited the site like you outlined a CSRF attack could still be perpetrated by first opening an iframe to the cookie generating page.
Yea I know the focus thingy wouldn't protect. I found several flaws with that approach.
Damn I want to find another approach.
I did find something. If I create a random token upon logon and pass it into the form field names like remove_admin_asd25dfgdfgdfgg43554=1, then I would do in the PHP script like
Code: Select all
if isset get["remove_admin".token]
remove the admin...
So this is basically CSRF, but not exactly. Instead of placing a CSRF token in GET/POST, I place it in the form field name. I doubt my friend pays me for this one though..