4 ms·

I don't understand why your post is flagged. You are 100% right. The point of CSRF protection is that -you can't trust the client-. This new header can just be

I don't understand why your post is flagged. You are 100% right. The point of CSRF protection is that -you can't trust the client-. This new header can just be set in curl, If I understand correctly. Unlimited form submissions here I come!

eptcyka 1y ago
CSRF protects the user by not allowing random pages on the web using resources from a target website, without the user being aware of this. It only makes sense when serving people using browsers. It is not a defense against curl or skiddies.
- nchmy 1y ago
  To elaborate/clarify a bit, we defend against curl with normal auth, correct? Be it session cookies or whatever. That plus origin/Sec-Fetch-Site (and tls, secure cookies, hsts) should be reasonable secure, no?
  - tankenmate 1y ago
    indeed, you need some form of CSRF, but the Sec-Fetch-Site is primarily focused on keeping a browser secure, not the server. Having said that it's nice defence in depth for the server as well but not strictly required as far as the server is concerned.
    - nchmy 1y ago
      I'm confused. In my mind, you only really need to keep the server secure, as that's where the data is. Auth cookies and csrf protections (eg Sec-Fetch-Site) are both used towards protecting the server from invalid requests (not logged in, or not coming from your actual site). What are you referring to when you talk about keeping the browser secure?
      - tankenmate 1y ago
        The Sec-Fetch-Site header can't be read / written by Javascipt (or WASM, etc), cookies (or some other tokens) on the other hand can be. In most circumstances allowing Javascript to access these tokens allows for "user friendly" interfaces where a user can log in using XMLHttpRequest / API rather than using a form on a page. OOB tokens one a one off auth basis or continuous (i.e. OAuth, TOTP with every request) are more secure, but obviously requires more engineering (and comes with its own "usability" / "failure mode" trade offs).
        nchmy 1y ago
        > The Sec-Fetch-Site header can't be read / written by Javascipt Perfect. It's not even meant or needed to be. The server uses it to validate the request came from the expected site. As i and others have said in various comments, you seem to be lost. Nothing you're saying has any relevance to the topic at hand. And, in fact, is largely wrong.
        tankenmate 1y ago
        "Nothing you're saying has any relevance to the topic at hand. And, in fact, is largely wrong."; your confidence in your opinion doesn't make you right. Prove it.
        deleted 1y ago
        [deleted]
kokada 1y ago
This is not what this is supposed to protect, and if you are using http.CrossOriginProtection you don't even need to add any header to the request: > If neither the Sec-Fetch-Site nor Origin headers are present, then it assumes the request is not coming from web browser and will always allow the request to proceed.
- nchmy 1y ago
  Wait, but if those headers are missing, then isn't there a vulnerability if someone is using an old browser and clicks on a malicious link? Do we need to also check user agent or something else?
  - kokada 1y ago
    Exactly, the post talks about this too: older browsers will be vulnerable, this probably affects only a small amount of the population and it is even lower if you limit service to accept TLSv1.3 (for this to be useful you of course need to enable HTTPS otherwise the attacker can just strip the headers from your request). If you can't afford to do this you still need to use CSRF tokens.
    - nchmy 1y ago
      I suppose that we could just reject anything that doesnt have these tokens, depending on whether you want to allow curl etc... I might just do that, in fact.

eptcyka 1y ago

CSRF protects the user by not allowing random pages on the web using resources from a target website, without the user being aware of this. It only makes sense when serving people using browsers. It is not a defense against curl or skiddies.

nchmy 1y ago
To elaborate/clarify a bit, we defend against curl with normal auth, correct? Be it session cookies or whatever. That plus origin/Sec-Fetch-Site (and tls, secure cookies, hsts) should be reasonable secure, no?
- tankenmate 1y ago
  indeed, you need some form of CSRF, but the Sec-Fetch-Site is primarily focused on keeping a browser secure, not the server. Having said that it's nice defence in depth for the server as well but not strictly required as far as the server is concerned.
  - nchmy 1y ago
    I'm confused. In my mind, you only really need to keep the server secure, as that's where the data is. Auth cookies and csrf protections (eg Sec-Fetch-Site) are both used towards protecting the server from invalid requests (not logged in, or not coming from your actual site). What are you referring to when you talk about keeping the browser secure?
    - tankenmate 1y ago
      The Sec-Fetch-Site header can't be read / written by Javascipt (or WASM, etc), cookies (or some other tokens) on the other hand can be. In most circumstances allowing Javascript to access these tokens allows for "user friendly" interfaces where a user can log in using XMLHttpRequest / API rather than using a form on a page. OOB tokens one a one off auth basis or continuous (i.e. OAuth, TOTP with every request) are more secure, but obviously requires more engineering (and comes with its own "usability" / "failure mode" trade offs).
      - nchmy 1y ago
        > The Sec-Fetch-Site header can't be read / written by Javascipt Perfect. It's not even meant or needed to be. The server uses it to validate the request came from the expected site. As i and others have said in various comments, you seem to be lost. Nothing you're saying has any relevance to the topic at hand. And, in fact, is largely wrong.
        tankenmate 1y ago
        "Nothing you're saying has any relevance to the topic at hand. And, in fact, is largely wrong."; your confidence in your opinion doesn't make you right. Prove it.
        deleted 1y ago
        [deleted]

kokada 1y ago

This is not what this is supposed to protect, and if you are using http.CrossOriginProtection you don't even need to add any header to the request: > If neither the Sec-Fetch-Site nor Origin headers are present, then it assumes the request is not coming from web browser and will always allow the request to proceed.

nchmy 1y ago
Wait, but if those headers are missing, then isn't there a vulnerability if someone is using an old browser and clicks on a malicious link? Do we need to also check user agent or something else?
- kokada 1y ago
  Exactly, the post talks about this too: older browsers will be vulnerable, this probably affects only a small amount of the population and it is even lower if you limit service to accept TLSv1.3 (for this to be useful you of course need to enable HTTPS otherwise the attacker can just strip the headers from your request). If you can't afford to do this you still need to use CSRF tokens.
  - nchmy 1y ago
    I suppose that we could just reject anything that doesnt have these tokens, depending on whether you want to allow curl etc... I might just do that, in fact.