0

We are hosting customer created scripts (xlst). I am wondering if it would affect the security of our application if we allow customers to refer to fonts hosted at e.g. fonts.googleapis.com? Since they would be refered by a link tag, it should never be able to run any JavaScript content?

Normally those external fonts would be allowed, but since I am developing a application for a industry sector which is very sensitive I have to take much more care.

  • Can't you host the fonts as well? – A. Hersean Feb 14 '17 at 14:23
  • Yes i can host is myself too. Thx. – Kr15 Feb 14 '17 at 15:16
  • Quick note: It sounds like you're trying to determine if you should blacklist link tags to prevent XSS. Rather, you should be determining a list of tags that can be whitelisted. More importantly, you should also whitelist attributes. Take following as example: <link rel="stylesheet" href="/doesNotExist.css" onerror="alert(document.cookie);" /> See also owasp.org (specifically owasp.org/index.php/Cross-site_Scripting_(XSS) ) – Ghedipunk Feb 14 '17 at 21:07
3

In theory, you're fine loading stylesheets and fonts from a third party - as you say, they're included in link tags, which shouldn't allow script execution. There are a few things which might cause information leakage though, and a potential for a targeted attack resulting in data appearing to change.

In terms of information leakage, browsers by default send a referer header when loading a resource. This will be sent to the font provider, and, if your links are structured in a way where you're attempting to use length or unknown values in the URL as a protection method, the font provider would be able to bypass that. If you're performing session checks, though, as most websites with authenticated sections in do, the third party shouldn't get the authentication tokens (usually cookies). Given that you're working in a sensitive industry, I'd hope this wasn't the case.

In terms of data appearing to change, a malicious font provider could supply fonts which are mapped incorrectly. Imagine if they supplied icons in a font, and you're using either a tick or a cross to indicate, for example, whether a blood sample was found to have a specific disease. By mapping the "tick" symbol to the "cross" value, and vice versa, an end user might think they've got some disease due to seeing this in the output. This would be a very targeted attack, so would probably only apply in very specific cases. This is unlikely to happen with Google Fonts, but could apply if you allowed linking to arbitrary web fonts.

Note that it would be possible for any stylesheet to perform similar attacks - for sensitive data, it's generally worth keeping anything that can modify the behaviour or appearance of the application hosted locally, unless you have specific requirements making this impossible.

For sensitive data, I'd advise hosting the fonts (and any other stylesheets and scripts) yourself, if possible, just for peace of mind.

  • Style sheets also allow UI redress attacks of which you have mentioned. e.g. Restyling some user content so that it looks to come from the application itself. – SilverlightFox Feb 14 '17 at 15:52
  • True. I'll update to mention that. – Matthew Feb 14 '17 at 15:54
1

Font files cannot contain client-side script.

You would however need to allow the locations within any Content Security Policy you will be using (font-src directive), therefore this will be technically weaker, but not exploitable.

And of course you should properly validate that they cannot circumvent any restrictions on inserting the link element to insert JavaScript instead (e.g. closing the <link/> and starting a <script> somehow. The details of which will be unique to your application, so I can't really comment on here in a general answer.

TLDR: This should be safe as long as you take the basic measures of security on board within your implementation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.