CSP can be circumvented in HTML5 using obsolete <font>

[mattok]

I have an HTML5 document on a website that uses Content-Security-Policy to block all inline styles; the idea being that all styling is managed via separate CSS stylesheets. I was therefore shocked to discover that styling can be overridden within the source by introducing <font> elements to change, for example, the colour of the text. I tried this across several different browsers, and realised that they all did the same thing.

<font> elements are obsolete in HTML5. I am by no means an expert in HTML5 standard-speak, but on investigation it appears to me that HTML5 allows <font> elements to be rendered, even though they are obsoleted. Since the most simple and robust method for translating a <font> element into something that is HTML5 compliant would be to replace it by a <span style=""> element, it occurs to me that it would be good if the standard would require that it is treated as such from the point of view of CSP.

I notice that CSP is already mentioned in relation to other obsolete elements, such as applet.

[chaals]

@mkwest ping...

[wolfbeast]

Extending coverage of CSP to include legacy style changes that are not tied to CSS but tied to legacy HTML elements (whose actual purpose is to provide (in-line) styling in HTML itself) is not going to be trivial to implement, and I think actually falls outside of CSP's scope.

CSP is meant to be a supportive measure that can not ever mitigate legacy, bad, or outdated code in the pages themselves. It shouldn't try to become more than it is.

Quoting Dan Veditz (Mozilla Security):

I'm not too worried about this because it doesn't allow for XSS or bypassing content-loading restrictions which are the main thrust of CSP. It's a tiny part of what <style> can do, but other than making some text disappear or fill up the page it can't move content around or other transformations that style can do.

As an aside: IMHO the suggested implementation of replacing elements in actual document code is not a good approach - too many things can go wrong with that.

[mattok]

CSP is meant to be a supportive measure that can not ever mitigate legacy, bad, or outdated code in the pages themselves. It shouldn't try to become more than it is.

For what it's worth, I disagree with @wolfbeast. How the obsoleted elements came to be in the document (that is, whether they were there because it's a legacy document, or because they were injected via some vulnerability, or whatever...) is irrelevant. The fact is that HTML allows obsoleted elements to be rendered. It does not make sense if CSP only provides its protections to valid HTML elements and attributes, ignoring legacy elements that do exactly the same thing albeit in a different way.

Now, if someone looks into this and decides that the fact that these legacy elements work in a different way (i.e. only allowing a limited range on non-dangerous style changes to be made, and not allowing the full range of possibilities that a style attribute would), means that they don't pose the same threat as for current elements, and so do not need to be protected by CSP then that's fine.

The font element in particular, allows the user to select a font-face. Perhaps the following hypothetical example is too far-fetched to be worth worrying about, but I would be concerned that with the current CSP, if an attacker has a list of vulnerable fonts that are on the system, and CSP has been set up to prevent anything other than fonts under the control of the author to be used, the <font> element to could be used to get around it. It's that kind of scenario that I think needs attention by people who are better qualified than me to judge the risks.

[wolfbeast]

Now, if someone looks into this and decides that the fact that these legacy elements work in a different way (i.e. only allowing a limited range on non-dangerous style changes to be made, and not allowing the full range of possibilities that a style attribute would), means that they don't pose the same threat as for current elements, and so do not need to be protected by CSP then that's fine.

This is exactly the reason why this isn't a threat -- in-line legacy elements that control a very limited subset of styling aren't even close to posing the same threat as using a full style attribute (e.g. as on a <span>) because they are not able to transform or re-arrange content, and as such should most definitely fall outside of scope for CSP.
The only (theoretical) threat with <font> would be if a pre-determined loaded font family would pose a threat to security (e.g. by way of font rendering vulnerabilities); but that is most certainly not in the realm of CSP to determine or mitigate, even more so because a <font> tag can't define the actual font to be loaded (unlike CSSes @font-face); it can only reference a font family to use. Any vulnerabilities there would be in the realm of the client to mitigate (e.g. through sanitation of loaded font faces and sane rendering practices) and not the responsibility of CSP to cover.

[jcobban]

Paraphrase of old joke:

Patient: "Doctor it hurts when I use <font>."
Doctor: "Then don't use <font>."

Within the domain of a CSP the owner of the site has the authority to enforce web standards. The administrator of the site can use grep to ensure that obsolete tags are not used.

[mattok]

What I'm hearing hearing is; if you have a lot of legacy HTML, which you want to keep online (an archive of newsletters dating back 20 years for example), you can not safely do so without making changes. CSP will only help neutralise from a security point of view to a certain extent. It won't help with obsolete elements/attributes. To take advantage of CSP, you've got to rewrite it as strict HTML5 (using grep or whatever filter/method you care for).

However, even with valid HTML5, if it either contains obsolete elements/attributes, or comes to contain such obsolete elements/attributes through some misconfiguration or vulnerability (injection) or whatever, then this is also something that CSP will not protect against.

I think it would be easier if obsolete elements/attributes weren't rendered within HTML5 documents at all to be honest (out at the very list, some kind of 'strict mode' flag that would do the same thing, but since the specification requires such elements to be rendered, then I'd hope that they would fall under the protection of CSP.

[AmeliaBR]

I agree that this isn't a Content Security Policy issue, since the presentational markup cannot affect the rest of the page, nor can it trigger file fetch (other than for webfonts defined elsewhere). If the primary goal is to enforce a consistent style, there are established CSS methods to do so.

<font> tags and other obsolete presentation markup are implemented in browsers (as far as I know) at the user-agent (browser) stylesheet level, the same as default styles for headings or links. They are not !important rules; they can be over-ridden by any author style rules on the same element.

To de-activate <font> elements, you can add the following rule to your stylesheet:

font {
  font: inherit;
  color: inherit;
}

Test case on CodePen

You could add similar style resets for other legacy formatting HTML tags, like <center>.

[chaals]

I think we should close this issue. It's not clear what practical security risks are opened.

ping @mkwest

[chaals]

Apparently nobody has identified a serious risk of a proper attack. Closing the issue for now.