A fundamental question about CSRF attacks

I am migrating from programming to 'web programming', so this may sound too basic

My question is about a HTTP request that is responded by "victim site" with some "non-public/sensitive" information as HTML or XML or JSON.

And victim site is just relying on session cookies for authentication before responding with "non public" info for the http request.

If a the hacker's site has a JS that makes ajax HTTP request to "victim site" and user is already logged in to "victim site" 开发者_运维问答and hence has cookie for victim site in browser.

Will the ajax request be responded by "victim server" and if so can the hackers JS post this "non-public" info back to hackers site.

How would one prevent this?

1. You cannot make a request through AJAX to other domain than the one where the JS with the AJAX is being executed.

   If the victim's site is example.com and hacker's site is example2.com then a JS file from example2.com can't make an AJAX request to another site outer than example2.

2. The cookies from the victim's server that the client has won't be sent to the hacker's server in an HTTP request. The cookies can be stolen if the victim's site has a XSS that can be exploited to send the cookies from that site to hackers.

Wikipedia has a few quick bits of advice: http://en.wikipedia.org/wiki/Csrf

Keep your session cookie lifetimes short. If you're logged out after 15 minutes of inactivity, you're less likely to fall victim to problems. Not very friendly, but it's something to consider based on the value of your data.

Check Referer: headers to see they came from your site. Not great. Not even good. But it's something.

Use user-specific form contents to prevent attackers from creating a simple form POST: Understanding the Rails Authenticity Token This mechanism is great, and if your framework helps you with it, nearly painless on your end. If your framework doesn't help you, then it's one more reason to consider a nicer framework. :)

ajax in the strict sense (xmlhttprequest), indeed is generally considered to be limited to the same domain, but a lot (if not everything) depends on the way browsers implement the security model. one thing I noticed is that Firefox will issue a cross-domain request even with normal (non cross-domain) ajax, but it blocks the entire response from coming in (looks like it aborts the request, leading to http 206 response code). that means that, at least in firefox, "write calls" need to be protected against CSRF attacks even for normal ajax.

next to browser glitches like this, most browsers also support 'cross domain resource sharing' which can be used with xmlhttprequests as well. when done the correct way, cross domain ajax can be pretty safe.

but adoption of CORS seems to hampered by the success of 'jsonp'; dynamically inserted scripts that contain data in json wrapped in a callback parameter which are not limited by the same domain principel. doing this the safe way (i.e. preventing an attacker site to dynamically insert and execute script from the victim site for a logged on user for which the cookie would indeed be sent along) is somewhat more difficult (requiring a session-alike token in each request which is not in the cookie).

conclusion: read-operations using traditional ajax are safe, for writes & jsonp you'll have to do some extra work to be safe. if you really want to go cross domain, you should probably look into CORS as an alternative to jsonp.