Firefox 90 supports Fetch Metadata Request Headers(blog.mozilla.org)
blog.mozilla.org
Firefox 90 supports Fetch Metadata Request Headers
https://blog.mozilla.org/security/2021/07/12/firefox-90-supports-fetch-metadata-request-headers/
108 comments
Does that mean that the quest of finding a working direct link to the image/video will soon become impossible?
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 ;=) ).
There's a difference between only allowing that behaviour, and explicitly creating features to enable it.
This sounds like Referer, but worse.
This sounds like Referer, but worse.
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.
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.
(1) How is it like Referer?
(2) How is Referer bad? Like it "tracks" you? Seems like the 1000th least bad tracker you probably run.
The thousandth least bad thing is still a bad thing.
? Referer contains tracking information. This doesn't..
[deleted]
Exactly - why do I as a user want this? I already need an extension to fake the Referer...
How can you be sure you actually need to send a Referer header. Whats the (user) benefit of sending one. I never send Referer and I have never had any problems as result.
I remove unwanted headers from requests generated by user agents I cannot adequately control, e.g., graphical web browsers, using a loopback-bound forward proxy. Perhaps this will be another one to remove.
I remove unwanted headers from requests generated by user agents I cannot adequately control, e.g., graphical web browsers, using a loopback-bound forward proxy. Perhaps this will be another one to remove.
Some websites (IIRC twitter does) open link differently based on the referrer header, so automatically sending a twitter referref for all twitter links improves your experience.
There might be more critical uses
There might be more critical uses
Twitter does not require a Referer header to return user-generated content ("tweets").
https://news.ycombinator.com/item?id=27056734
Sending a Referer header does not improve [your] experience. It is the opposite for me. I cannot tolerate Twitter's Javascript, I do not use a graphical browser. I find it annoying when people submit Twitter status messages to HN.
I have a script that reformats the JSON into a simple HTML page with no Javascript. This improves the experience for me:
https://news.ycombinator.com/item?id=27499784
https://news.ycombinator.com/item?id=27056734
Sending a Referer header does not improve [your] experience. It is the opposite for me. I cannot tolerate Twitter's Javascript, I do not use a graphical browser. I find it annoying when people submit Twitter status messages to HN.
I have a script that reformats the JSON into a simple HTML page with no Javascript. This improves the experience for me:
https://news.ycombinator.com/item?id=27499784
Protect against cross-site vulnerabilities.
Which extension?
The article explains why you as a user want this.
Developer tools / Network / find necessary resource / Right click / Copy as cURL
Can you provide an example of such a "quest"?
The only speed bumps I have encountered are timestamps, i.e., links that "expire".
The only speed bumps I have encountered are timestamps, i.e., links that "expire".
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?
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#fe...
This spec seems really powerful, provided all browser support it :)
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fe...
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.
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.
Safari truly is IE in 2021
Let's completely sidestep the whole debate that we always have. This is a safety feature, Safari will implement it, you can bet on it. It's merely going to be the last to do it.
And yet safari is the last major browser to implement it.
[deleted]
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.
And even for the same reason: If the browser was too good "no one" (very loosely defined here) would need to buy Apps anymore. :(
I don’t quite understand this argument. Can you give me a couple examples of Safari holding back major parts of web design? Or is it more obscure stuff like some webGL engine?
Because I use Safari specifically for privacy reasons and it also used to never trigger my fans to full speed just to play videos, like Chrome. I also have read that while Safari does tend to take longer, their implementations tend to be more polished. But this was more like a tweet so take that anecdata with a grain of salt.
Because I use Safari specifically for privacy reasons and it also used to never trigger my fans to full speed just to play videos, like Chrome. I also have read that while Safari does tend to take longer, their implementations tend to be more polished. But this was more like a tweet so take that anecdata with a grain of salt.
I often try to use a feature and it doesn't work properly on one browser. It's nearly always mobile safari. This week, I've dealt with scroll-snap (which makes URL anchors work correctly with a sticky header) being supported but only for some layouts (every other browser works).
Today I spent hours debugging why pages with a particular iframe embed would log you out of the parent site on Safari / iOS. Possibly because the same first-party resource was requested from both outside and inside the frame? Not sure yet.
If you attempt to use localStorage from a private tab on safari, it reports that it's present and working, but raises an exception on any access (every other platform either does not expose localStorage in private tabs, or clears it after).
Today I spent hours debugging why pages with a particular iframe embed would log you out of the parent site on Safari / iOS. Possibly because the same first-party resource was requested from both outside and inside the frame? Not sure yet.
If you attempt to use localStorage from a private tab on safari, it reports that it's present and working, but raises an exception on any access (every other platform either does not expose localStorage in private tabs, or clears it after).
Absence of push notifications makes it impossible to develop a lots of web apps.
Also more user-friendly way to install desktop shortcut would help tremendously to make web apps more popular. Of course Apple is not interested with that, but it's still sad.
Also more user-friendly way to install desktop shortcut would help tremendously to make web apps more popular. Of course Apple is not interested with that, but it's still sad.
Here are some examples: https://infrequently.org/2021/04/progress-delayed/
An an user, safari is great. Has a web developer, safari is hell.
This is a story that you can often hear on HN but I don't think it's correct.
There were three correlated reasons for the bad reputation of IE some years ago:
1. it was largely dominant, so people thought they could develop just taking that browser in consideration
2. for the previous point, MS started to develop proprietary features (like ActiveX)
3. at a certain point its development was stopped for a long time
Safari certainly cannot match the first two reasons. But it cannot match the third either, because the development of standard web features is going on at good pace (see <https://webkit.org/status/>).
1. it was largely dominant, so people thought they could develop just taking that browser in consideration
2. for the previous point, MS started to develop proprietary features (like ActiveX)
3. at a certain point its development was stopped for a long time
Safari certainly cannot match the first two reasons. But it cannot match the third either, because the development of standard web features is going on at good pace (see <https://webkit.org/status/>).
Counterpoints:
> Safari certainly cannot match the first two reasons.
1. Most users view websites on their phones. Safari is the only browser on iPhone (there are other browser skins, but they're all forced to run on top of Safari). The market share of iOS devices is usually about at least 50% in developed nations.
2. iOS has proprietary features, it is known as the App Store. If you want to develop certain things, you must use the app store, the browser is locked out of those features (even if all other browser vendors have them).
> But it cannot match the third either, because the development of standard web features is going on at good pace (see <https://webkit.org/status/>).
3. I probably don't need to go into this point since it's common knowledge that Safari has always been the least compliant browser in terms of web standards. Their history of holding back features or implementing features with critical flaws that make them useless has been a recurring trend for the last decade. Just because they have checked a box on a table, doesn't mean the feature is anything close to useable.
> Safari certainly cannot match the first two reasons.
1. Most users view websites on their phones. Safari is the only browser on iPhone (there are other browser skins, but they're all forced to run on top of Safari). The market share of iOS devices is usually about at least 50% in developed nations.
2. iOS has proprietary features, it is known as the App Store. If you want to develop certain things, you must use the app store, the browser is locked out of those features (even if all other browser vendors have them).
> But it cannot match the third either, because the development of standard web features is going on at good pace (see <https://webkit.org/status/>).
3. I probably don't need to go into this point since it's common knowledge that Safari has always been the least compliant browser in terms of web standards. Their history of holding back features or implementing features with critical flaws that make them useless has been a recurring trend for the last decade. Just because they have checked a box on a table, doesn't mean the feature is anything close to useable.
Right now but you can reasonably develop a website which will work in Chrome and Firefox even without testing (not talking about any supper modern features), but Safari is riddled with bugs you wouldn't expect. Recently I have encountered multiple bugs regarding svg clipping in safari. Safari 14 also broke localstorage and indexeddb it's almost funny how bad safari is at actually just working.
My homepage is tiny and absolutely nothing fancy, but I've still managed to immediately run into at least two Chrome bugs.
Well I found some chrome bugs, but here is the thing after I reported them, they have been immediately responded to and fixed and released in nearest version. Safari though you have to wait a year for bug fixes to be released, if they even acknowledge you at all inside their bug tracker the only way to get Webkit people attention is tag them on twitter.
Those might be the reasons why users disliked IE, but the reason developers dislike IE were/are somewhat different:
1. It doesn't support many of the latest web standards
2. A large enough percentage of users use it that it can't be simply ignored
Both of those points apply to modern Safari. Less so to IE these days as #2 becomes less and less applicable; hence "Safari is the new IE".
1. It doesn't support many of the latest web standards
2. A large enough percentage of users use it that it can't be simply ignored
Both of those points apply to modern Safari. Less so to IE these days as #2 becomes less and less applicable; hence "Safari is the new IE".
Developers hated having to work around missing features for IE even when FF and Chrome took over the market, Safari is the exact same, except you can't even update the rendering engine on iOS, Apple doesn't want webapps to eat away at app store profit (notice how shitty and slow moving the webgl/webgpu thing has been mostly due to iOS Safari)
People who say this never had to develop for IE.
Yep, I don't know why my first thought was that malicious actors could just bypass this by using external HTTP clients (like curl) when in fact this spec is meant to augment CORS: browsers _will_ send these headers to the server and the server can choose to honour them or not (well, in the CORS case the browser will block the request if the response headers are incorrect).
It's defense in depth :D
It's defense in depth :D
> supper-seeded
I think you meant superseded (pronounced super-seeded).
I think you meant superseded (pronounced super-seeded).
Fascinating, TIL that superseded is correct and superceded is and has been wrong for four hundred years :):
https://www.merriam-webster.com/dictionary/supercede
https://www.merriam-webster.com/dictionary/supercede
It seems silly to me too but re reading 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.”
“ 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.”
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/mod...
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/mod...
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.
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.
> Is the origin header flawed in some way?
tl;dr yes. It's not always sent.
tl;dr yes. It's not always sent.
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
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
[deleted]
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.
> 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.
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.
It is FUD. They claim your bank website is most likely susceptible to this attack. It is not.
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.
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.
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.
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
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.
Perhaps as a fallback for when somebody forgets to use a token for an input. Thanks!
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?
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.
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.
Some example code on how to use these headers to allow/reject requests:
https://web.dev/fetch-metadata/#step-5:-reject-all-other-req...
https://web.dev/fetch-metadata/#step-5:-reject-all-other-req...
Does this essentially solve XSRF? Would it no longer be necessary to use XSRF tokens?
Yes, that's the idea.
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]
One other notable candidate for essentially "solving" XSRF is SameSite cookies:
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-sti...).
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-sti...).
In the example, couldn't the call from attacker.com to banking.com be thwarted by CORS headers defined by the server?
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.
But of course, the server could reject no-cors requests, or any request missing an Origin header.
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.
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.
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.
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.
So basically CORS headers that works as expected. Excellent.
dbg31415(3)
drtgh(4)
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...
I've been following their work pretty closely, but I'm at a loss trying to think of anything...
- 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
- 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
Not experiencing bank fraud thanks to improved security controls is pretty good UX.
For the people wondering what the motivation is, 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.