Hot answers tagged

16

The 'Site' in SameSite refers to a the combination of second level domain mysite.com and top level domain mysite.com. This means that a requests from login.mysite.com to cdn.mysite.com would be considered a same-site request. BUT... as you might imagine it does not end there. There is the Public Suffixes List which slightly changes this validation ...


5

I think the main point of confusion here is that the Django docs are specifically talking about the CSRF use case for a cookie. In order to understand why the httpOnly flag adds no value in preventing CSRF, you need to understand both CSRF and how cookies work. CSRF is when a 3rd party triggers your user's browser to make a request to your server, and their ...


5

One thing I would add to the other answers is that CSRF protection is necessary only in the domain and path of the cookie in question. Or put another way: Authorization != Authentication Cookies == Authentication Token == Authorization This is relevant to the implementation of persistent logins (your 3rd point). If you affix your cookies to login....


4

Firefox 67 and 68 added multiple possible settings for privacy and Third-Party-Cookie-Blocking. As far as I understand, your demo seems to include usage of Third-Party-Cookies. You can find the information at the information page about content-blocking from Mozilla. The main reason for the change were protecting against being tracked by Third-Party-...


4

However, how is this safe? A malicious website can do the exact same thing, hit my log in, receive the token, add to token to header, and then do anything. The malicious website could grab a csrf token, but as your server will have a different csrf token for each user session, it will be of no use to the malicious website. To better understand csrf attacks,...


4

Let me explain the specification. The definition of "same-site" is : A request is "same-site" if its target's URI's origin's registered domain is an exact match for the request's client's "site for cookies", or if the request has no client. The request is otherwise "cross-site". For a given request ("request"), the following ...


4

The custom HTTP header works as a defense in and of itself. Actually, one rudimentary form of CSRF protection is to simply set a custom header to a constant non secret value and then check for it server side. This protection is sometimes applied unknowingly by simply requireing certain content-type headers. OWASP describes this technique: Adding CSRF tokens,...


3

Double-submit cookies was always a relatively weak CSRF protection, at least as typically implemented. Any attacker who can set a cookie - either via a cookie injection vulnerability in the app or via man-in-the-middle (MitM) attack - can defeat the typical implementation of double-submit cookies; this has been known for many years. It also requires that the ...


3

This question is your friend: CSRF protection with custom headers (and without validating token) In essence, if you opt to make your X-CSRFToken header something simple like 1, you are falling back simply on the presence of your custom header for CSRF protection. If you have a fixed CSRF token for all users, then an attacker will easily be able to figure ...


3

If you have XSS, you can do literally anything that a script on the page could do. Read all the user's data on that site. Steal secrets (for that site) from their local storage. Prompt them to download malicious files from the trusted site. Tamper with the path to any file they do download, before they get it. Impersonate them in posts (on that site). Delete ...


3

Does it make sense to summarise all this as follows: SOP (Single Origin Policy) ensures CSRF attacks can't be made from within a modern, up to date, browser due to the fact that the attacker would have to be POSTing from another domain. CSRF (Cross-Site Request Forgery) tokens ensure that dangerous POST requests can't be made outside of the browser (where ...


3

Doesn't this seem much simpler than the current system of generating, keeping track of, and reading secure CSRF tokens? No, because this measure would only protect against state changing endpoints (e.g. HTTP POST of form data), but the other flavor of CCRF is just having a user click on a maliciously formed link ( e.g. check out this facebook <a href="...


3

This is currently changed in Chrome - and this means that not setting SameSite is actually considered LAX. https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html


3

Same-origin policy prevents a website from reading another website, which also prevents it from extracting the token to perform a CSRF attack.


3

The only way CSRF prevention with double-submitting can work is by sending the nonce in a cookie. If you send it in the HTTP response body, it can in some cases be parsed out by a script sending a cross-domain request, (if you've allowed CORS for that page) which defeats the whole purpose of protecting against CSRF. The idea is that scripts on domain X can’t ...


3

If there is an XSS vulnerability, the attacker has won. If you can execute arbitrary JavaScript on the victims machine in the target origin, you can do whatever you want - you don't need to bypass any CSRF protection to wreak havoc. Also, no CSRF protections survive an XSS vulnerability. A referer header check does not help, since the attacker can just send ...


3

... but what if someone uses XHR to retrieve the page containing the csrf token The capabilities of such a cross-site XHR are restricted by the Same Origin Policy and could be extended by CORS. Without CORS explicitly allowing cross-site reading and also sending of the credentials (session cookie) it would not be possible for an attacker to do an XHR where ...


3

No it's not possible to circumvent this CSRF-protection in a classical CSRF attack. Using the user-agent- header to submit the anti-CSRF-token is just like using any custom header, which is one of the currently preferred methods of CSRF-protection. An attacker could only 'fake' the user agent via a XSS, or a malign browser extension (or browser). But in such ...


2

The httpOnly attribute can be omitted from the anti-CSRF cookie in Django because, as many other answers and even the question highlighted, javascript code running in victim browsers that loaded an unauthorized origin will not be able to read authenticated responses from the authorized origin, with or without the attribute, due to Same Origin Policy. (Let'...


2

Sure. This is actually one of my preferred approaches. It makes the strength of your CSRF protection wholly dependent on the strength of your session token security, but session takeover strictly dominates CSRF in impact anyhow. The hashing means you can leave your session token in an HttpOnly cookie and not expose the session to JavaScript in any way. ...


2

Bit of a rambling question, so bit of a rambling answer also. CSRF can also be defended by including a custom header on XHR requests, and with same site cookies. CORS is not variously defined; it is a W3C standard. What sometimes causes confusion is that CORS is not really a security mechanism. Cross-origin data leaking is an area of active research and ...


2

I can't tell if you independently re-invented double-submit cookies and didn't think anybody'd thought of it before, or just didn't do any research on a well-known topic. https://duckduckgo.com/?q=double+submit+cookie+weakness&ia=web has no lack of results, including some from this very site (see Double Submit Cookies vulnerabilities and Is the double ...


2

You are correct, but this requires a specific and rather unusual behavior of the protected web application to work. You are referring to the chapter "CSRF token is simply duplicated in a cookie" from the portswigger guide. Let me quote the essential part and highlight the crucial "if": In this situation, the attacker can again perform a CSRF attack if ...


2

it seems protecting GET resources with CSRF tokens is useless. It's not useless if you have state-changing GET request (which you shouldn't have, but it does happen). Do I need to implement some CSRF token protection for the endpoint? No, requests which do not change state do not need CSRF protection (they may need proper authorization though). Could ...


2

In order for cookies to be sent with cross-site requests, .withCredentials must be set to True in the cross-site request. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS for more info (scroll down to the section 'Requests with credentials').


2

A CSRF attack can only be done with requests with those three http request content types: application/x-www-form-urlencoded, multipart/form-data and text/plain. If your end point checks the request content type and makes sure it is not one of those three, that end point is protected from CSRF. So if you make the request content type be something like ...


2

Is there any way to use an external form (like the one above) to send a malformed GET request with POST data to achieve this CSRF A GET request with a body has no meaning. To cite RFC 7231 section 4.3.1: A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to ...


2

You cannot explicitly set any HTTP headers in a HTML form apart from choosing the Content-Type between two predefined values. This means you also cannot set some x-forwarded-host header.


1

I have also noticed an uprising of storing JWT's in LocalStorage, but thankfully recently some developers are making articles on why not to do that. This is a pretty broad topic and in no way I am for storing JWT tokens in LocalStorage, because your one XSS vulnerability away to get blown to bits, but the thought process behind it is pretty legit. Two ...


1

Short answer: No, there's no way to have the benefit of Strict SameSite without the drawbacks of Strict SameSite. However, you can get most of the benefits (and fewer drawbacks) by using Lax SameSite. I think you quite badly misread that article you linked. Google is not, and has no plans to, change the default SameSite behavior to Strict. All they are ...


Only top voted, non community-wiki answers of a minimum length are eligible