1163536 - Font files not secure

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[53branman]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.6.3 (KHTML, like Gecko) Version/8.0.6 Safari/600.6.3

Steps to reproduce:

I have a set of self-hosted fonts for a website. They are located on the same server as the website which has https. I use the following method in an .htaccess file to help prevent them being hot linked or directly downloaded:

RewriteCond "%{HTTP_HOST}_%{HTTP_REFERER}" "!\.?([^\.]+\.[^\.]+?)_https?://.*\1/.*$"
RewriteRule \.(woff|eot|svg|ttf)$ - [F,NC,L]


Actual results:

Using Firefox 37.0.2, I am able to download those files without obstruction. Here’s how:

1. Inspect element containing self-hosted font and copy the URL for the font from the web inspector.
2. Enter that URL into Firefox’s address bar and hit return to download/save the file.


Expected results:

These files should not be accessible for direct download by the user.

If I simply enter the font’s URL without visiting the site, I am unable to download these files, as expected. Visiting the site first and downloading these fonts to the browser is what appears to allow these files to be saved by the user.

Can you explain why this happens and if it is indeed a bug?

Comment 1

[:Gijs (he/him)]

Your technique is based on something like http://serverfault.com/a/105544 - it's meant to prevent hotlinking by checking that the referer (sic) header uses the same host as the one passed as the host for the request. Because the fonts are used from your main page, the referrer is set to your webhost when requesting them, which is why the fonts work in the first place.

Regarding how it works when using the inspector... presumably the referrer is being passed and so your server is allowing access. It's not clear to me exactly what page you're testing with and how you're requesting the font, so it's hard to check if it's "wrong" that we're passing the referrer. Can you provide a test page?

(I'm marking this as non-sec-sensitive because really, there is no reasonable way on the public web to have a resource be both publicly available and not downloadable. The referer trick is as old as methusalem but won't stop a determined web-literate person, nor is this a security bug in Firefox, and so there's no point keeping this bug hidden.)

Comment 2

[53branman]

I will look into providing more information but for obvious reasons would like to keep this post private. I have made this private again. If that is not agreeable, please delete this post. Thank you.

Comment 3

[:Gijs (he/him)]

(In reply to dev from comment #2)
> I will look into providing more information but for obvious reasons would
> like to keep this post private. I have made this private again.

I don't understand what the "obvious" reasons are to make this private. There is no identifiable, private information in this bugreport, beyond the email address you used to report this with. You could change that in your user preferences if desired. Can you elaborate?

For some background, Mozilla tries to be as open as possible; we can't delete items from this database without involving the bugzilla admins, and I don't think we would do so unless there are very very very serious reasons. The overwhelming majority of this bug database is public; we normally only use security-sensitive for issues relating to security problems with our software or that of other vendors, which isn't the case here.

Comment 4

[53branman]

The potential bug was reported to me by a type foundry who beleive their fonts are less secure becuase of this issue, and do not want this method exposed. It only appears to be an issue in the latest version(s) o Firefox. No other browser does this as far as we are aware. Whether or not it is a security issue seems subjective, espcially until the issue is fully understood. Would you agree?

Comment 5

[:Gijs (he/him)]

(In reply to 53branman from comment #4)
> The potential bug was reported to me by a type foundry who beleive their
> fonts are less secure becuase of this issue, and do not want this method
> exposed.

OK. As I noted, fundamentally the assumption that you could both protect and provide the resource is flawed. The fonts are still copyrighted regardless of how they're made available, and I would suggest that that would be the appropriate way for the type foundry to pursue issues with their font being abused without the appropriate rights.

> It only appears to be an issue in the latest version(s) o Firefox.
> No other browser does this as far as we are aware.

Without some page to test this with, this is very hard to verify/understand. It seems you're saying this is not an apache configuration issue, and Firefox has no magical powers to override your apache configuration, which means that either the data is coming from cache, or the referer header is being sent. It could be wrong that we're sending the referer header, but it might also be intentional. We'd need to know more. Likewise, caching (and serving from cache) may or may not be wrong here, but it's hard to tell without a test page, its headers and meta elements etc. It could just be that we've made different decisions than other browsers regarding caching/referrers.

> Whether or not it is a
> security issue seems subjective, espcially until the issue is fully
> understood. Would you agree?

It seems unlikely this is a security issue. Generally, caching and referrer sending can be security issues if they compromise the user's security, and you want this to be an issue because of the security of the served (non-user-private, non security sensitive) content, which fundamentally won't work. It's possible that you have, perhaps somewhat inadvertently, discovered a user-impacting security issue, but to figure that out we really need more information and detailed steps to reproduce.

Comment 6

[53branman]

A public example, right now, would be apple.com. 

Visit https://www.apple.com/wss/fonts/Myriad-Set-Pro/v1/myriad-set-pro_ultralight.woff and you might see a 404. However, visit https://www.apple.com first, and then the previous URL, you might see the issue.

I hope that helps. Thank you for your replies.

Comment 7

[:Gijs (he/him)]

This works in Chrome as well.

1. open https://www.apple.com/
2. open the chrome developer tools
3. go to "resources" and expand "frames" and then "www.apple.com" and then "fonts"
4. right click any of the fonts
5. click "copy URL"
6. copy-paste the URL into the location bar

and the font will automatically download.

This works because of the caching implied by the headers - Firefox (and presumably Chrome, too) doesn't even hit the network, it just takes the font file out of the cache, because the response headers say:

Cache-Control: max-age=30706089
Connection: keep-alive
Content-Length: 96840
Content-Type: application/font-woff
Date: Mon, 11 May 2015 13:21:57 GMT
Expires: Sat, 30 Apr 2016 22:50:06 GMT
Last-Modified: Fri, 01 May 2015 18:20:39 GMT
Server: Apache

The browser is therefore quite right to cache the file, and not talk to the server when the same file is requested a second time. The images on the same site use an ETag, which means that on a refresh, they are requested again. It's possible that doing the same for the fonts would "help" - but note that all kinds of devtools make it easy to replay requests with cURL, which will easily avoid all this "protection".

Comment 8

[Justin Dolske [:Dolske]]

Definitely not a browser security issue.

Mechanisms like this to prevent users from downloading content are basically just speedbump to prevent casual downloads. Someone can use any of a plethora of tools to make (curl and wget being two popular ones) to make HTTP requests with arbitrary headers set, or any of a number of other techniques to copy files once the browser has them.

Comment 9

[53branman]

(In reply to :Gijs Kruitbosch from comment #7)

Thank you for the information on caching. Do you know how sites like fontdeck.com are able to avoid this issue, or do you have any other recommendations?