Firefox 90 supports Fetch Metadata Request Headers(blog.mozilla.org) |
Firefox 90 supports Fetch Metadata Request Headers(blog.mozilla.org) |
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.
This sounds like Referer, but worse.
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.
The only speed bumps I have encountered are timestamps, i.e., links that "expire".
> 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.
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.
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.
https://web.dev/fetch-metadata/#step-5:-reject-all-other-req...
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...).
I've been following their work pretty closely, but I'm at a loss trying to think of anything...
- 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
This spec seems really powerful, provided all browser support it :)
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#fe...
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.
“ 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.”
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...
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.
tl;dr yes. It's not always sent.
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.
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.
There might be more critical uses
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:
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.
> allows web applications to protect themselves and their users against various cross-origin threats
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 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".
> 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.
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.
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).
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.
It's defense in depth :D