CSRF Tokens In Cookies.

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

CSRF Tokens In Cookies.

Post 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.
Last edited by kaisellgren on Mon Feb 02, 2009 7:22 pm, edited 3 times in total.
André D
Forum Commoner
Posts: 55
Joined: Thu Aug 28, 2008 7:03 pm

Re: CSRF Tokens In Cookies.

Post 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
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: CSRF Tokens In Cookies.

Post 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 :P

EDIT: My current system works seamlessly :P tried CSRF with GET and POST did not work. I'm using JS now.
Last edited by kaisellgren on Mon Feb 02, 2009 7:04 pm, edited 1 time in total.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: CSRF Tokens In Cookies.

Post 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.
André D
Forum Commoner
Posts: 55
Joined: Thu Aug 28, 2008 7:03 pm

Re: CSRF Tokens In Cookies.

Post 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.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: CSRF Tokens In Cookies.

Post 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 :P
André D
Forum Commoner
Posts: 55
Joined: Thu Aug 28, 2008 7:03 pm

Re: CSRF Tokens In Cookies.

Post by André D »

Do not rely on JavaScript to do such a thing. What if the user has JavaScript disabled?
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: CSRF Tokens In Cookies.

Post 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.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: CSRF Tokens In Cookies.

Post 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...
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: CSRF Tokens In Cookies.

Post 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.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: CSRF Tokens In Cookies.

Post 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/
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: CSRF Tokens In Cookies.

Post by kaisellgren »

pytrin wrote: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/
Thanks, I'll have a look at them!
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: CSRF Tokens In Cookies.

Post 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.
aschlosberg
Forum Newbie
Posts: 24
Joined: Fri Jan 23, 2009 10:17 pm

Re: CSRF Tokens In Cookies.

Post 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.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: CSRF Tokens In Cookies.

Post 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..
Post Reply