CSRF vulnerability / cookies question

Just want to get input fro开发者_JS百科m people who know. I was considering CSRF vulnerabilities, and the seemingly the most popular method I know to fight against it. That method is to create a token in the returned html and adding a cookie with the same value. So if a script tries to do a post they would have to guess the token thats embedded in the web page for it to be successful.

But if they're targeting a specific website why can't they just use a script that

1. Calls a get on the page (the cookie will be returned even though the script can't access it)
2. Parses the html and gets the token
3. Calls a post with that token in it (the cookie that came back will be sent back)
4. They've successfully submitted a form without the users knowledge

The script doesn't need to know the contents of the cookie, it's just using the fact that cookies get sent back and forth all the time.

What am I missing here? Is this not possible? I think this is pretty scary if you think about it.

Below this line is not required reading to answer the question :)

This vulnerability banks on the fact that authentication is done based on cookies, which I think is the main way authentication is currently occurring.

Another solution I can think of is making authentication be on the page level. So when they log in the returned html will have that token in it. every link that they click contains that token so when the web server gets a request it has a way to identify the user/session. The problem with it is that if they use any navigation other than that they will be 'unauthenticated'(e.g. type in a url) , also it doesn't look nice in the url because it would probably look something like this:

https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3

But I do understand that if safety is more important, then a pretty URL is second place.

I don't know everything about cookies but what if user agents were a little more careful with their cookies?

For example, what if the cookies sent depended on the tab? We all surf using tabs by now, right? so what if the scope of the cookie was the tab? so if i have my banking site open on tab 1 and i'm surfing on tab 2, any scripts calling gets/posts on tab 2 will only send the cookies accrued in tab 2.

Or what if cookies were stored / domain. So while I'm on example.com any cookies that come back go into the example.com cookie collection. and then when i'm on www.mybankingsite.com all the cookies get put into the mybankingsite.com collection. So if I go to example.com and it runs a script that calls a get/post the user agent will only send example.com cookies. This is different than sending the cookies of the requested domain. E.g. if a script calls a get of mybankingsite.com within a web page of example.com the user agent will not send the mybankingsite.com cookies.

I know i have no control over what user agents do, but I'm just exploring possibilities

So I think the problem here becomes the attacker's attempt to get the page's contents. To get the authenticated user's page, the attacker needs to be able to send a request on their behalf and read the contents. AJAX won't send cross-domain requests, iframes won't let you read the response. I am struggling to think of other ways in which an attacker would get the contents first.

A more likely hack is using clickjacking to have the user just submit the form. This technique doesn't seem too likely. (caveat: it's security, we can always be wrong.)

Does anyone care to share some code on this issue as I just hacked my own site (Not in production) with CSRF. All I had to do was the following

At: www.badguy.com/ write the following html

img src="www.goodguy.com/secure/user/delete/5">

What this does So the admin goes to to www.badguy.com/ and the the image makes a request to www.goodguy.com/secure/user/delete/5 from the users browser so the admin unknowingly just deleted a user. If you create a loop your in some trouble. Expect I never delete data just change its status :) but still I don't like the looks of this.

The CSRF token has to be unique per session. If a malicious server requests the same page, they will get a different token. If they try to request the contents of the page via JavaScript on the client's machine, the same-origin policy will prevent them.