10 ms·

Firefox 90 supports Fetch Metadata Request Headers

260 points by ykat7 5y ago

wronex 5y ago
How is this different from the origin header? Does the origin header not tell the webbserver if the requested originated from the same website? Is the origin header flawed in some way?
- taf2 5y ago
  It seems silly to me too but re reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Or... “ There are some exceptions to the above rules; for example if a cross-origin GET or HEAD request is made in no-cors mode the Origin header will not be added.”
  - elken 5y ago
    That's an interesting find thanks. I was not aware of no-cors mode. It seems though that a browser would not allow 'non-simple' headers in no-cors mode[0]. Authorization headers for example would not be allowed (if i'm reading correctly). So any API using that header would not be affected by this issue right? [0] https://developer.mozilla.org/en-US/docs/Web/API/Request/mode#value https://developer.mozilla.org/en-US/docs/Web/API/Request/mod...
- alexghr 5y ago
  Reading the documentation on MDN[1] it looks like it sends more data than just the Origin of the request. Metadata headers include if the user initiated the request (e.g. navigation or click events?) and how the data is meant to be used (e.g. as audio data for <audio> or a top-level document). This spec seems really powerful, provided all browser support it :) [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fetch_metadata_request_headers https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fe...
  - dathinab 5y ago
    Firefox, Chrome, Edge and Opera support it (including mobile). Internet Explorer is dead (ok, is a Zombie. But was supper-seeded by Edge for most users). Safari is sadly not yet supported. The nice thing is that you can employ security enhancements based on this technique even if it's not supported by all your clients. I.e. you can automatically reject requests if the headers are given and have a bad value, which would add additional protection against certain attacks for all users except the ones stuck on IE or Safari.
    - drchickensalad 5y ago
      Safari truly is IE in 2021
      - deleted 5y ago
        [deleted]
      - Dah00n 5y ago
        I have done web-development both in the bad IE days but also recently and IMO it wasn't as bad to develop for IE as it is for Safari today. Safari is broken in strange and random ways and missing odd features and is a moving target (and seem to break more with time). Developing for IE was extremely well documented (especially in later versions) and avoiding pitfalls was very easy, even for people new to creating webpages using a few Google searches. Not so for Safari - unless you cut it completely off from all modern advances on the web. It just felt worse back then because IE was much more widespread.
        vanviegen 5y ago
        Were you actually doing any serious web development in the mid 2000s? Because I have a feeling you wouldn't be saying this if you were.. :-)
        Dah00n 5y ago
        I can see that came out wrong. I'll try to rephrase...
- paulddraper 5y ago
  > Is the origin header flawed in some way? tl;dr yes. It's not always sent.
  - deleted 5y ago
    [deleted]
  - wronex 5y ago
    This is true. Could we not disregard requests without an origin header? According to [0] we can force CORS behaviour be using a non-simple request in our webapp. By setting the mime type to JSON for example. 0: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- dec0dedab0de 5y ago
  If all the parts of the site are at the same place, then checking an origin header would probably do the same thing. This seems to be adding semantics for when the frontend is requesting data from a different backend, as well as for specific types of content, and if it was based on a user action. The user action part is very nice if it can't be overwritten with just javascript. The other parts I'm not sure what the browser is helping with, that can't just be done with standard headers.
drtgh 5y ago
Since Encrypted SNI was disabled in Firefox 85, all the hostnames are transferred in plaintext, even using HTTPS. It was also disabled from Firefox ESR 78 at one point around ESR 78.9 This Not only makes DNS over HTTPS absolutely useless, but it is also giving browsing information by duplicate, to the ISP, to the intermediaries and to the DNS providers. From the article, "If you aren’t a Firefox user yet, you can download the latest version here to start benefiting from all the ways that Firefox works to protect you when browsing the internet" I did not expected Firefox 90 forget about this matter and talk about protection, when they got rid of Encrypted SNI in FF 85 without warning, and without having any other alternative actively working. We went from an incomplete solution (ESNI) to having nothing at all. Meanwhile ECH (encrypted client hello) keep sounding like vaporware by the moment. Please...
- ChrisSD 5y ago
  If ESNI is fundamentally flawed, how is it better than nothing at all? At that point isn't it just cargo cult "protection"?
  - contravariant 5y ago
    You're gonna have to support the statement that ESNI is fundamentally flawed a bit better for that argument to work.
    - lallysingh 5y ago
      From Mozilla link above: Since publication of the ESNI draft specification at the IETF, analysis has shown that encrypting only the SNI extension provides incomplete protection. As just one example: during session resumption, the Pre-Shared Key extension could, legally, contain a cleartext copy of exactly the same server name that is encrypted by ESNI. The ESNI approach would require an encrypted variant of every extension with potential privacy implications, and even that exposes the set of extensions advertised. Lastly, real-world use of ESNI has exposed interoperability and deployment challenges that prevented it from being enabled at a wider scale.
anonymfus 5y ago
Does that mean that the quest of finding a working direct link to the image/video will soon become impossible?
- dathinab 5y ago
  If site producers want to it's already pretty much impossible today. At least without some "tricks", and nothing prevents your video-downloader from just adding a header which pretend it's origin is a website. (Or more funny you inject the downloading JS code into the website in question extending it with a download functionality ;=) ).
  - userbinator 5y ago
    There's a difference between only allowing that behaviour, and explicitly creating features to enable it. This sounds like Referer, but worse.
    - will4274 5y ago
      ? Referer contains tracking information. This doesn't..
    - dathinab 5y ago
      Sec-Fetch-Site: It's more like `Origin`but without actually containing the Origin instead just delivering information about if it's the same site, same origin different origin or has not origin. This makes it much more privacy friendly then both the `Origin` and `Refer` header, it also makes it easier to user for the intended use case and in turn IMHO a strict improvement over both `Origin` and `Referer`. Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-User: Provide a bit more context about how the request was made, while this can leak slightly more information compared to `Origin` or worse `Referer` it's still much better. So from a privacy POV I would say this is a strict improvements. From a functionality POV it might look like it further limits 3rd party resource re-usage but CORS already does so. And like CORS it can be circumvented by using download apps which are not your browsers or servers republishing things or similar. I could imagine there could be some web-extensions which "extend" a website by injecting code or similar which would become harder to do with this. Through I don't know of any where there isn't a reasonable workaround. So from what I can tell the worst thing it might do is that using `curl` for sites where you need to set a `Origin` header now also need you to set some other headers which could be annoying.
dbg31415 5y ago
Any idea when they'll fix Firefox so you can make streaming calls without turning your MBP into a toaster? 40x the battery usage vs. Safari when on a streaming call. It's so painful. Heh, literally. The machine gets too hot to hold comfortably. It's still my primary browser, but optimization is needed. Sucks to have to change browsers just to make calls. We live on streaming calls now. This has been an issue since at least the start of Covid when I first really noticed it.
- llacb47 5y ago
  what is a streaming call? webrtc applications like google meet?
  - dbg31415 5y ago
    Google Meet, Zoom, etc.
- floatingatoll 5y ago
  That sounds like a reproducible bug report, with an easy test case (“run this script and measure laptop battery life, in Firefox and Safari”). If you haven’t already provided that in a bug report to the software developers, you should do so. Shopping your concern to an unrelated thread about security headers isn’t likely to get far on HN, certainly nowhere near as much as a testable bug would.
  - dbg31415 5y ago
    Eh, I'm willing to take a few downvotes if it means raising awareness. I tag pretty much every Firefox post with some sort of report on battery life. I've added bug reports... doesn't ever seem to get taken seriously. Like I said I'm OK with taking a few downvotes on the off chance someone on the Firefox team may actually see this and be able to prioritize work to address the issue. Firefox is my primary browser, but this issue in the age of Covid makes it fundamentally flawed. Heard all the responses, "Stop trying to use Firefox on a Mac, it's Apple's fault..." and not unsympathetic, just feels more can be done.
boba7 5y ago
Have they fixed the 8 yo confirmed bugs yet?
amluto 5y ago
I’m quite surprised that Sec-Fetch-Dest doesn’t have a “form” type for form submissions, and the spec makes almost no mention of forms. Does this spec finally allow a simple header check to squash CSRF form posts or not?
TazeTSchnitzel 5y ago
Does this essentially solve XSRF? Would it no longer be necessary to use XSRF tokens?
- alexghr 5y ago
  I think they could replace XSRF tokens, but until all major browsers support the headers (Safari 11 seems to be missing support, see other comments) you can't really block requests that don't have the new Sec-Fetch-* headers.
  - deleted 5y ago
    [deleted]
- ddworken 5y ago
  One other notable candidate for essentially "solving" XSRF is SameSite cookies: https://web.dev/samesite-cookies-explained/ https://web.dev/samesite-cookies-explained/ SameSite cookies are supported in Safari and IE11, so they're potentially a better candidate, but there are still come caveats (see here for some of them: https://security.stackexchange.com/questions/234386/do-i-still-need-csrf-protection-when-samesite-is-set-to-lax https://security.stackexchange.com/questions/234386/do-i-sti...).
- paulddraper 5y ago
  Yes, that's the idea.
barbazoo 5y ago
In the example, couldn't the call from attacker.com to banking.com be thwarted by CORS headers defined by the server?
- ddworken 5y ago
  In the web, requests are made in either `cors` mode or `no-cors` mode. In `cors` mode, the `Origin` header is sent in the request. So yes, in `cors` mode the server could reject the request based on the `Origin` header. But in `no-cors` mode (the default if you do something like `<img src='...'>`) the `Origin` header isn't set, so CORS doesn't help defend against any attacks.
  - jonny_eh 5y ago
    But of course, the server could reject no-cors requests, or any request missing an Origin header.
  - staticassertion 5y ago
    Can you explain the risk with regards to no-cors requests? Like presumably an attacker requesting an image isn't scary, right? I'd think the real issue would be the attacker making credential'd requests.
    - bmm6o 5y ago
      The point is that the endpoint can be anything, it doesn't need to have anything to do with images. But because of the context of the request, it's no cors.
      - staticassertion 5y ago
        Right but that's why CORS exists, so I'm trying to figure out what this mitigation is for. Like, you can't just fetch with credentials by accident - I guess if you don't use http cookies, which sure that's fine, maybe you can? This isn't my area of security so I'm trying to figure out what the scenario is supposed to be where this mitigation is important.
ec109685 5y ago
This is FUD: > Hence the banking server or generally web application servers will most likely simply execute any action received and allow the attack to launch. While these are useful headers, there are protections today via XSRF tokens to prevent these attacks that all major sites implement, so it isn’t likely your bank is vulnerable.
- aj3 5y ago
  It's not FUD. There are protections, but csrf tokens are a workaround while these headers are more akin to proper solution. Also, it won't magically make CSRF obsolete same way Origin header and CORS didn't make CSRF obsolete, but it's another tool in the appsec toolbox.
  - ec109685 5y ago
    It is FUD. They claim your bank website is most likely susceptible to this attack. It is not.
gentleman11 5y ago
Pardon my ignorance. I thought the way to deal with csrf was csrf tokens. It seems like you would still have to ignore the headers and rely on the token in your logic if ever they disagreed. I’m not sure how to use these new headers
- aj3 5y ago
  CSRF tokens have overhead and they have to be implemented for all inputs which isn't trivial (judging by amount of CSRF related vulnerabilities disclosed in hacker one reports). I think the intention here is to make cross site requests stand out so that they can be dealt with in a more streamlined/uniform fashion.
  - gentleman11 5y ago
    Perhaps as a fallback for when somebody forgets to use a token for an input. Thanks!
jefftk 5y ago
Very happy to see this landing in Firefox! For the people wondering what the motivation is, https://www.w3.org/TR/fetch-metadata/#intro https://www.w3.org/TR/fetch-metadata/#intro has a good summary: Interesting web applications generally end up with a large number of web-exposed endpoints that might reveal sensitive data about a user, or take action on a user’s behalf. Since users' browsers can be easily convinced to make requests to those endpoints, and to include the users' ambient credentials (cookies, privileged position on an intranet, etc), applications need to be very careful about the way those endpoints work in order to avoid abuse. Being careful turns out to be hard in some cases ("simple" CSRF), and practically impossible in others (cross-site search, timing attacks, etc). The latter category includes timing attacks based on the server-side processing necessary to generate certain responses, and length measurements (both via web-facing timing attacks and passive network attackers). It would be helpful if servers could make more intelligent decisions about whether or not to respond to a given request based on the way that it’s made in order to mitigate the latter category. For example, it seems pretty unlikely that a "Transfer all my money" endpoint on a bank’s server would expect to be referenced from an img tag, and likewise unlikely that evil.com is going to be making any legitimate requests whatsoever. Ideally, the server could reject these requests a priori rather than delivering them to the application backend. Here, we describe a mechanism by which user agents can enable this kind of decision-making by adding additional context to outgoing requests. By delivering metadata to a server in a set of fetch metadata headers, we enable applications to quickly reject requests based on testing a set of preconditions. That work can even be lifted up above the application layer (to reverse proxies, CDNs, etc) if desired.
AtNightWeCode 5y ago
So basically CORS headers that works as expected. Excellent.
rob-olmos 5y ago
Some example code on how to use these headers to allow/reject requests: https://web.dev/fetch-metadata/#step-5:-reject-all-other-requests-that-are-cross-site-and-not-navigational https://web.dev/fetch-metadata/#step-5:-reject-all-other-req...
ajb 5y ago
The original CORS protection is enforced by the browser, not the server. That means that it is much harder for it to cause a privacy problem. Given that this only works if you are using a browser anyway (any other user agent can spoof all this) I don't see how there can be any security gain from the server doing the enforcement. Which leaves me wondering whether the increased flexibility is worth the potential privacy issue.
- hsbauauvhabzb 5y ago
  CORS doesn’t protect against CSRF. CORS also permits the initial request, where this change will permit the server to drop the clients request. The problem is the header isn’t really usable until uptake is substantial, dropping requests now creates a workflow deviation based on user agent, meaning while some gain security, the header cannot be relied on entirely.
forgotmypw17 5y ago
Is there anything Mozilla/Firefox has done in the past 10 years that at least CAN BE ARGUED is for the improvement of the user's experience? I've been following their work pretty closely, but I'm at a loss trying to think of anything...
- hsbauauvhabzb 5y ago
  Not experiencing bank fraud thanks to improved security controls is pretty good UX.
- lelandbatey 5y ago
  - creating multi-account container extension - getting onto webextension based extensions has allowed Firefox to become much snappier than it used to be - Firefox sync for history syncing is fantastic - Firefox on mobile (Android) is a delight and the only browser I use on mobile now - Rust (from Mozilla) is cool and is being used to build cool and important things
mousepilot 5y ago
For me, recent firefox releases have been MISERABLE. I guess it could just be my computers but the browser constantly locks, no performance whatsoever, and just no help on troubleshooting anywhere. I went with the long term support releases and have had a better experience. Course, still no sound lol but I use Chrome when I want sound. I still like Firefox, just can't use recent releases.

260 points by ykat7 5y ago

How is this different from the origin header? Does the origin header not tell the webbserver if the requested originated from the same website? Is the origin header flawed in some way?

taf2 5y ago
It seems silly to me too but re reading https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Or... “ There are some exceptions to the above rules; for example if a cross-origin GET or HEAD request is made in no-cors mode the Origin header will not be added.”
- elken 5y ago
  That's an interesting find thanks. I was not aware of no-cors mode. It seems though that a browser would not allow 'non-simple' headers in no-cors mode[0]. Authorization headers for example would not be allowed (if i'm reading correctly). So any API using that header would not be affected by this issue right? [0] https://developer.mozilla.org/en-US/docs/Web/API/Request/mode#value https://developer.mozilla.org/en-US/docs/Web/API/Request/mod...
alexghr 5y ago
Reading the documentation on MDN[1] it looks like it sends more data than just the Origin of the request. Metadata headers include if the user initiated the request (e.g. navigation or click events?) and how the data is meant to be used (e.g. as audio data for <audio> or a top-level document). This spec seems really powerful, provided all browser support it :) [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fetch_metadata_request_headers https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fe...
- dathinab 5y ago
  Firefox, Chrome, Edge and Opera support it (including mobile). Internet Explorer is dead (ok, is a Zombie. But was supper-seeded by Edge for most users). Safari is sadly not yet supported. The nice thing is that you can employ security enhancements based on this technique even if it's not supported by all your clients. I.e. you can automatically reject requests if the headers are given and have a bad value, which would add additional protection against certain attacks for all users except the ones stuck on IE or Safari.
  - drchickensalad 5y ago
    Safari truly is IE in 2021
    - deleted 5y ago
      [deleted]
    - Dah00n 5y ago
      I have done web-development both in the bad IE days but also recently and IMO it wasn't as bad to develop for IE as it is for Safari today. Safari is broken in strange and random ways and missing odd features and is a moving target (and seem to break more with time). Developing for IE was extremely well documented (especially in later versions) and avoiding pitfalls was very easy, even for people new to creating webpages using a few Google searches. Not so for Safari - unless you cut it completely off from all modern advances on the web. It just felt worse back then because IE was much more widespread.
      - vanviegen 5y ago
        Were you actually doing any serious web development in the mid 2000s? Because I have a feeling you wouldn't be saying this if you were.. :-)
        Dah00n 5y ago
        I can see that came out wrong. I'll try to rephrase...
paulddraper 5y ago
> Is the origin header flawed in some way? tl;dr yes. It's not always sent.
- deleted 5y ago
  [deleted]
- wronex 5y ago
  This is true. Could we not disregard requests without an origin header? According to [0] we can force CORS behaviour be using a non-simple request in our webapp. By setting the mime type to JSON for example. 0: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
dec0dedab0de 5y ago
If all the parts of the site are at the same place, then checking an origin header would probably do the same thing. This seems to be adding semantics for when the frontend is requesting data from a different backend, as well as for specific types of content, and if it was based on a user action. The user action part is very nice if it can't be overwritten with just javascript. The other parts I'm not sure what the browser is helping with, that can't just be done with standard headers.

drtgh 5y ago

Since Encrypted SNI was disabled in Firefox 85, all the hostnames are transferred in plaintext, even using HTTPS. It was also disabled from Firefox ESR 78 at one point around ESR 78.9 This Not only makes DNS over HTTPS absolutely useless, but it is also giving browsing information by duplicate, to the ISP, to the intermediaries and to the DNS providers. From the article, "If you aren’t a Firefox user yet, you can download the latest version here to start benefiting from all the ways that Firefox works to protect you when browsing the internet" I did not expected Firefox 90 forget about this matter and talk about protection, when they got rid of Encrypted SNI in FF 85 without warning, and without having any other alternative actively working. We went from an incomplete solution (ESNI) to having nothing at all. Meanwhile ECH (encrypted client hello) keep sounding like vaporware by the moment. Please...

ChrisSD 5y ago
If ESNI is fundamentally flawed, how is it better than nothing at all? At that point isn't it just cargo cult "protection"?
- contravariant 5y ago
  You're gonna have to support the statement that ESNI is fundamentally flawed a bit better for that argument to work.
  - lallysingh 5y ago
    From Mozilla link above: Since publication of the ESNI draft specification at the IETF, analysis has shown that encrypting only the SNI extension provides incomplete protection. As just one example: during session resumption, the Pre-Shared Key extension could, legally, contain a cleartext copy of exactly the same server name that is encrypted by ESNI. The ESNI approach would require an encrypted variant of every extension with potential privacy implications, and even that exposes the set of extensions advertised. Lastly, real-world use of ESNI has exposed interoperability and deployment challenges that prevented it from being enabled at a wider scale.

anonymfus 5y ago

Does that mean that the quest of finding a working direct link to the image/video will soon become impossible?

dathinab 5y ago
If site producers want to it's already pretty much impossible today. At least without some "tricks", and nothing prevents your video-downloader from just adding a header which pretend it's origin is a website. (Or more funny you inject the downloading JS code into the website in question extending it with a download functionality ;=) ).
- userbinator 5y ago
  There's a difference between only allowing that behaviour, and explicitly creating features to enable it. This sounds like Referer, but worse.
  - will4274 5y ago
    ? Referer contains tracking information. This doesn't..
  - dathinab 5y ago
    Sec-Fetch-Site: It's more like `Origin`but without actually containing the Origin instead just delivering information about if it's the same site, same origin different origin or has not origin. This makes it much more privacy friendly then both the `Origin` and `Refer` header, it also makes it easier to user for the intended use case and in turn IMHO a strict improvement over both `Origin` and `Referer`. Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-User: Provide a bit more context about how the request was made, while this can leak slightly more information compared to `Origin` or worse `Referer` it's still much better. So from a privacy POV I would say this is a strict improvements. From a functionality POV it might look like it further limits 3rd party resource re-usage but CORS already does so. And like CORS it can be circumvented by using download apps which are not your browsers or servers republishing things or similar. I could imagine there could be some web-extensions which "extend" a website by injecting code or similar which would become harder to do with this. Through I don't know of any where there isn't a reasonable workaround. So from what I can tell the worst thing it might do is that using `curl` for sites where you need to set a `Origin` header now also need you to set some other headers which could be annoying.

dbg31415 5y ago

Any idea when they'll fix Firefox so you can make streaming calls without turning your MBP into a toaster? 40x the battery usage vs. Safari when on a streaming call. It's so painful. Heh, literally. The machine gets too hot to hold comfortably. It's still my primary browser, but optimization is needed. Sucks to have to change browsers just to make calls. We live on streaming calls now. This has been an issue since at least the start of Covid when I first really noticed it.

llacb47 5y ago
what is a streaming call? webrtc applications like google meet?
- dbg31415 5y ago
  Google Meet, Zoom, etc.
floatingatoll 5y ago
That sounds like a reproducible bug report, with an easy test case (“run this script and measure laptop battery life, in Firefox and Safari”). If you haven’t already provided that in a bug report to the software developers, you should do so. Shopping your concern to an unrelated thread about security headers isn’t likely to get far on HN, certainly nowhere near as much as a testable bug would.
- dbg31415 5y ago
  Eh, I'm willing to take a few downvotes if it means raising awareness. I tag pretty much every Firefox post with some sort of report on battery life. I've added bug reports... doesn't ever seem to get taken seriously. Like I said I'm OK with taking a few downvotes on the off chance someone on the Firefox team may actually see this and be able to prioritize work to address the issue. Firefox is my primary browser, but this issue in the age of Covid makes it fundamentally flawed. Heard all the responses, "Stop trying to use Firefox on a Mac, it's Apple's fault..." and not unsympathetic, just feels more can be done.

boba7 5y ago

Have they fixed the 8 yo confirmed bugs yet?

amluto 5y ago

I’m quite surprised that Sec-Fetch-Dest doesn’t have a “form” type for form submissions, and the spec makes almost no mention of forms. Does this spec finally allow a simple header check to squash CSRF form posts or not?

TazeTSchnitzel 5y ago

Does this essentially solve XSRF? Would it no longer be necessary to use XSRF tokens?

alexghr 5y ago
I think they could replace XSRF tokens, but until all major browsers support the headers (Safari 11 seems to be missing support, see other comments) you can't really block requests that don't have the new Sec-Fetch-* headers.
- deleted 5y ago
  [deleted]
ddworken 5y ago
One other notable candidate for essentially "solving" XSRF is SameSite cookies: https://web.dev/samesite-cookies-explained/ https://web.dev/samesite-cookies-explained/ SameSite cookies are supported in Safari and IE11, so they're potentially a better candidate, but there are still come caveats (see here for some of them: https://security.stackexchange.com/questions/234386/do-i-still-need-csrf-protection-when-samesite-is-set-to-lax https://security.stackexchange.com/questions/234386/do-i-sti...).
paulddraper 5y ago
Yes, that's the idea.

barbazoo 5y ago

In the example, couldn't the call from attacker.com to banking.com be thwarted by CORS headers defined by the server?

ddworken 5y ago
In the web, requests are made in either `cors` mode or `no-cors` mode. In `cors` mode, the `Origin` header is sent in the request. So yes, in `cors` mode the server could reject the request based on the `Origin` header. But in `no-cors` mode (the default if you do something like `<img src='...'>`) the `Origin` header isn't set, so CORS doesn't help defend against any attacks.
- jonny_eh 5y ago
  But of course, the server could reject no-cors requests, or any request missing an Origin header.
- staticassertion 5y ago
  Can you explain the risk with regards to no-cors requests? Like presumably an attacker requesting an image isn't scary, right? I'd think the real issue would be the attacker making credential'd requests.
  - bmm6o 5y ago
    The point is that the endpoint can be anything, it doesn't need to have anything to do with images. But because of the context of the request, it's no cors.
    - staticassertion 5y ago
      Right but that's why CORS exists, so I'm trying to figure out what this mitigation is for. Like, you can't just fetch with credentials by accident - I guess if you don't use http cookies, which sure that's fine, maybe you can? This isn't my area of security so I'm trying to figure out what the scenario is supposed to be where this mitigation is important.

ec109685 5y ago

This is FUD: > Hence the banking server or generally web application servers will most likely simply execute any action received and allow the attack to launch. While these are useful headers, there are protections today via XSRF tokens to prevent these attacks that all major sites implement, so it isn’t likely your bank is vulnerable.

aj3 5y ago
It's not FUD. There are protections, but csrf tokens are a workaround while these headers are more akin to proper solution. Also, it won't magically make CSRF obsolete same way Origin header and CORS didn't make CSRF obsolete, but it's another tool in the appsec toolbox.
- ec109685 5y ago
  It is FUD. They claim your bank website is most likely susceptible to this attack. It is not.

gentleman11 5y ago

Pardon my ignorance. I thought the way to deal with csrf was csrf tokens. It seems like you would still have to ignore the headers and rely on the token in your logic if ever they disagreed. I’m not sure how to use these new headers

aj3 5y ago
CSRF tokens have overhead and they have to be implemented for all inputs which isn't trivial (judging by amount of CSRF related vulnerabilities disclosed in hacker one reports). I think the intention here is to make cross site requests stand out so that they can be dealt with in a more streamlined/uniform fashion.
- gentleman11 5y ago
  Perhaps as a fallback for when somebody forgets to use a token for an input. Thanks!

jefftk 5y ago

Very happy to see this landing in Firefox! For the people wondering what the motivation is, https://www.w3.org/TR/fetch-metadata/#intro https://www.w3.org/TR/fetch-metadata/#intro has a good summary: Interesting web applications generally end up with a large number of web-exposed endpoints that might reveal sensitive data about a user, or take action on a user’s behalf. Since users' browsers can be easily convinced to make requests to those endpoints, and to include the users' ambient credentials (cookies, privileged position on an intranet, etc), applications need to be very careful about the way those endpoints work in order to avoid abuse. Being careful turns out to be hard in some cases ("simple" CSRF), and practically impossible in others (cross-site search, timing attacks, etc). The latter category includes timing attacks based on the server-side processing necessary to generate certain responses, and length measurements (both via web-facing timing attacks and passive network attackers). It would be helpful if servers could make more intelligent decisions about whether or not to respond to a given request based on the way that it’s made in order to mitigate the latter category. For example, it seems pretty unlikely that a "Transfer all my money" endpoint on a bank’s server would expect to be referenced from an img tag, and likewise unlikely that evil.com is going to be making any legitimate requests whatsoever. Ideally, the server could reject these requests a priori rather than delivering them to the application backend. Here, we describe a mechanism by which user agents can enable this kind of decision-making by adding additional context to outgoing requests. By delivering metadata to a server in a set of fetch metadata headers, we enable applications to quickly reject requests based on testing a set of preconditions. That work can even be lifted up above the application layer (to reverse proxies, CDNs, etc) if desired.

AtNightWeCode 5y ago

So basically CORS headers that works as expected. Excellent.

rob-olmos 5y ago

Some example code on how to use these headers to allow/reject requests: https://web.dev/fetch-metadata/#step-5:-reject-all-other-requests-that-are-cross-site-and-not-navigational https://web.dev/fetch-metadata/#step-5:-reject-all-other-req...

ajb 5y ago

The original CORS protection is enforced by the browser, not the server. That means that it is much harder for it to cause a privacy problem. Given that this only works if you are using a browser anyway (any other user agent can spoof all this) I don't see how there can be any security gain from the server doing the enforcement. Which leaves me wondering whether the increased flexibility is worth the potential privacy issue.

hsbauauvhabzb 5y ago
CORS doesn’t protect against CSRF. CORS also permits the initial request, where this change will permit the server to drop the clients request. The problem is the header isn’t really usable until uptake is substantial, dropping requests now creates a workflow deviation based on user agent, meaning while some gain security, the header cannot be relied on entirely.

forgotmypw17 5y ago

Is there anything Mozilla/Firefox has done in the past 10 years that at least CAN BE ARGUED is for the improvement of the user's experience? I've been following their work pretty closely, but I'm at a loss trying to think of anything...

hsbauauvhabzb 5y ago
Not experiencing bank fraud thanks to improved security controls is pretty good UX.
lelandbatey 5y ago
- creating multi-account container extension - getting onto webextension based extensions has allowed Firefox to become much snappier than it used to be - Firefox sync for history syncing is fantastic - Firefox on mobile (Android) is a delight and the only browser I use on mobile now - Rust (from Mozilla) is cool and is being used to build cool and important things

mousepilot 5y ago

For me, recent firefox releases have been MISERABLE. I guess it could just be my computers but the browser constantly locks, no performance whatsoever, and just no help on troubleshooting anywhere. I went with the long term support releases and have had a better experience. Course, still no sound lol but I use Chrome when I want sound. I still like Firefox, just can't use recent releases.