An attacker will try to trick the web browser into issuing a request to the server. The server will assume that the request is valid because it trusts the client.
At its most simple a CSRF attack could involve making a malicious form on a webpage that causes the client to send a POST request to a url.
Of course Facebook is not vulnerable to this, and neither should your code be.
The best way to mitigate CSRF attacks is to generate a very random token which you store in Alice's session. You then make sure that whenever your output a form on your site that you include this token in the form. Alice will send the token whenever she submits the form and you can compare it to the one stored in her session to make sure that the request is originating from your site.
Bob has no way of knowing what the token in Alice's session is and so he can't trick her browser into submitting it to our site. Our site will get a request from Alice's client but because it doesn't have the token we can reject it.
In other words the effect of the token is to stop relying on implicit trust for the client and rather set up a challenge response system whereby the client proves it is trustworthy. If Bob wants to send a request that will be accepted he must find a way to read a token off a form that your site has rendered for Alice. This is not a trivial task but can possibly be done - there are very creative ways (like this attack) to abuse requests.
Another way to prevent CSRF is to rely on multi-factor authentication. We can group ways to authenticate into knowledge (where you know something like a password), possession (where you have something like a USB dongle), or inherent (where you are something).
Instead of just relying on one of these mechanisms we can use two (or more) in order to authenticate. For example we can ask a person for a password and also require that they enter a code sent to the mobile phone which proves they have the mobile phone linked to their account.
CSRF will become much harder for Bob to accomplish if our form is protected with multi-factor authentication (MFA). Of course this comes with a user experience cost so only critical forms need to be protected with MFA. For less critical forms the single authentication method of a CSRF token will suffice.
There is debate around whether it is useful to check whether the referrer header matches your site is helpful in deterring CSRF. It is true that it is trivial to spoof this header in a connection that you control. However it is more difficult to get this level of control in a typical CSRF attack where browsers will rewrite the referrer header in an ajax call (see the specification). By itself it is not sufficient to deter CSRF, but it can raise the difficulty level for attackers.
Cookies should obviously not be used to mitigate CSRF. They are sent along with any request to the domain whether the user intended to make the request or not.
Setting a session timeout window can help a little bit as it will narrow the window that requests will be trusted by your application. This will also improve your session security by making it harder for fixation attacks to be effective.
Tokens are the most convenient way to make CSRF harder to accomplish on your site. When used in conjunction with referrer checks and a narrow session window you can make it significantly harder for an opponent to accomplish a successful attack.
For critically important forms multi-factor authentication are the way to go. They interrupt the user experience and enforce explicit authentication. This has a negative affect on your UX but makes it impossible (I think!) for an automated CSRF attack to be effective.