118
I wasn't originally aiming for a self-answer, but after more reading I've come up with what I believe to be a comprehensive answer that also explains why some might still be interested in CSRF protection on REST endpoints.
No cookies = No CSRF
It really is that simple. Browsers send cookies along with all requests. CSRF attacks depend upon this behavior. ...
105
For the reasons already discussed, it is not necessary to generate a new token per request. It brings almost zero security advantage, and it costs you in terms of usability: with only one token valid at once, the user will not be able to navigate the webapp normally. For example if they hit the 'back' button and submit the form with new values, the ...
70
SQL injection. If you use Django's object-relational mapper (ORM) layer, you are basically protected from SQL injection.
The only caveat is that you need to avoid manually forming SQL queries using string concatenation. For instance, do not use raw SQL queries (e.g., raw()). Similarly, do not use the extra() method/modifier to inject raw SQL. Do not ...
61
In theory your suggestion is perfectly reasonable. If browsers blocked all cross origin POST requests by default, and it required a CORS policy to unlock them, a lot of all the CSRF vulnerabilities out there would magically disappear. As a developer, you would only need to make sure to not change server state on GET requests. No tokens would be needed. That ...
52
As joe says, there is no real security benefit to this. It is pure security theater. I'd like to highlight this from the documentation:
If you enable this and need to send the value of the CSRF token with an AJAX request, your JavaScript must pull the value from a hidden CSRF token form input on the page instead of from the cookie.
The purpose of the ...
47
In a cross-site request forgery attack, the attacker tries to force/trick you into making a request which you did not intend. This could be sending you a link that makes you involuntarily change your password. A malicious link could look like that:
https://security.stackexchange.com/account?new_password=abc123
In a cross-site scripting attack, the attacker ...
46
This does not seem to be a CSRF vulnerability.
If an attacker needs to know a CSRF Token, then it's not an attack. And your approach to CSRf does seem to be correct.
Issues which leak the CSRF Token can indeed result in a CSRF attack, but then the problem isn't incorrect CSRF protection, but those issues (XSS, encryption, CSRF Token in URL, and so on).
...
45
I'll start my answer by saying that many people misunderstand the Same Origin Policy and what CORS brings to the table.
Some of the up-voted answers already here are stating that the Same Origin Policy prevents cross-site requests, and therefore prevents CSRF. This is not the case. All the SOP does is prevent the response from being read by another domain (...
39
This is called "Login CSRF" and is indeed a real problem that you should address.
While an attacker couldn't fool a victim to log in to their own account since the attacker doesn't know the user's credentials, an attacker could fool the victim into logging in to the attacker's account. This can be used to trick a victim into giving up information to the ...
38
Let's walk through how this attack works.
The Attack
I visit some client's website and start the process of authorizing that client to access some service provider using OAuth
The client asks the service provider for permission to request access on my behalf, which is granted
I am redirected to the service provider's website, where I would normally enter ...
36
Security is about defence in depth. Simply checking the value is sufficient at the moment, but future technologies and attacks may be leveraged to break your protection. Testing for the presence of a token achieves the absolute minimum defence necessary to deal with current attacks. Adding the random token improves the security against potential future ...
32
TL;DR - Checking the existence of a non-standard header like "X-Requested-By" should be sufficient to guard against CSRF attacks without checking the value of the header.
Non-standard headers cannot be set in a CSRF attack
The Play framework site breaks it down really well:
Simply put, an attacker can coerce a victims browser to make the following types ...
31
You must at the very least check for Content-Type: application/json on the request.
It's not possible to get a POSTed <form> to submit a request with Content-Type: application/json. But you can submit a form with a valid JSON structure in the body as enctype="text/plain".
It's not possible to do a cross-origin (CORS) XMLHttpRequest POST with Content-...
31
Possibly you should protect against Login CSRF. Without this protection an attacker can effectively reverse a CSRF attack. Rather than the victim being logged in to their own account and the attacker tries to ride the session by making requests to the site using the victim's cookies, they will be logging into the site under the attacker's credentials ...
28
This is relevant but doesn't necessarily answer 100% of your question:
https://security.stackexchange.com/a/166798/149676
The short of it is that as long as authentication isn't automatic (typically provided by the browser) then you don't have to worry about CSRF protection. If your application is attaching the credentials via an Authorization header then ...
26
CSRF protection is only needed for state-changing operations because of the same-origin policy. This policy states that:
a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.
So the CSRF attack will not be able to access the data it requests because it is a cross-...
25
If I understand you correctly, you are saying why is the browser blocking access to a resource that can be freely obtained over the internet if cookies are not involved? Well consider this scenario:
www.evil.com - contains malicious script code looking to exploit CSRF vulnerabilites.
www.privatesite.com - this is your external site, but instead of locking ...
24
Your understanding is correct.
Background
The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A: www.mybank.com and Tab B: www.attacker.com.
(As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if ...
23
First, a definition from Chrome:
Same-site cookies (née "First-Party-Only" (née "First-Party")) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.
So what does this protect against?
CSRF?
Same-site cookies can ...
22
Overview. The standard advice is to use a unique CSRF token that is unique for each request. Why? Because a per-request token is a bit more resilient to certain kinds of implementation errors than a per-session token. This makes per-request tokens arguably the best choice for new web application development. Also, no security auditor is going to hassle ...
22
A summary of how CSRF attacks work goes like this:
You, the good user, while logged into a web site A, visit some other site's page B.
That page does a GET (can be a POST, a little more complex to set
up) to a page X on site A (which you are logged in to), with e.g.
. Your browser obliges, using your already authenticated session/cookie
Page X by design ...
22
The problem is not the request method: CSRF could also be done with a GET request. The problem is instead that authentication information like (session) cookies or the Authorization header are automatically included with the cross-site request, thus making CSRF possible. Therefore the mitigation would not be to prohibit such methods to be used within cross ...
21
The basics
First, I assume you understand the most basic session ID security right:
you are using an ID with sufficient entropy, and
you use transport level security (HTTPS).
Any approach to session ID (URL, cookies, whatever) that does not get those right is vulnerable, your question is specifically about ID in URL, so I will not discuss that further.
...
20
Your question makes an assumption that should not be made in the field:
wouldn't you be able to detect and lock them out after a few attempts
Yes, in a good working environment there should be a system like this in place that rate-limits failures of various kinds. This is a good thing to do but it should never your first or only line of defense. If your ...
20
With anonymous cookies
If you are happy to generate secure tokens which are set as anonymous users' cookies, but not to store them server side then you could simply double submit cookies.
e.g. Legitimate user:
Anon user navigates to the login page, receives cookie which is sent to the browser.
Anon user logs in and the browser sends the cookie as a header ...
19
TL;DR
A JWT, if used without Cookies, negates the need for a CSRF token - BUT! by storing JWT in session/localStorage, your expose your JWT and user's identity if your site has an XSS vulnerability (fairly common). It is better to add a csrfToken key to the JWT and store the JWT in a cookie with secure and http-only attributes set.
Read this article with ...
19
Generally, CSRF happens when a browser automatically adds headers (i.e: Session ID within a Cookie), and then made the session authenticated. Bearer tokens, or other HTTP header based tokens that need to be added manually, would prevent you from CSRF.
Of course, but sort of off-topic, if you have a XSS vulnerability, an attacker could still access these ...
18
Short answer: To prevent brute forcing the CSRF token.
Let's take a trivial example: let's say your token is a single digit, accepting values from 0 to 9.
Now sure, an attacker cannot read this value from the cookie or header, but she does not have to - she can just have the attack send 10 CSRF requests, one with each possible value. One of them will be ...
18
I would probably take the following steps:
Identify a URL on your site where a CSRF attack could have a negative effect on your site. For this example lets say a GET request to http://mysite.com/account/del will delete the account you are logged in as
Next create a basic HTML page that is totally separate from the site you are testing. On this HTML page ...
Only top voted, non community-wiki answers of a minimum length are eligible
