W3C home > Mailing lists > Public > www-tag@w3.org > January 2019

Re: "Authoritative Metadata" standard, default mime types and XSS

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 11 Jan 2019 13:22:59 -0800
Cc: W3C TAG <www-tag@w3.org>
Message-Id: <A678221F-FC8B-418C-B8D2-2E59B8E0BBCE@gbiv.com>
To: Hanno Böck <hanno@hboeck.de>
> On Jan 10, 2019, at 11:38 PM, Hanno Böck <hanno@hboeck.de> wrote:
> Hello,
> I recently looked into a security issue that happens relatively easily
> in the way web severs and web applications are designed, I have
> multiple practical instances in popular web applications (Wordpress,
> Joomla, Mailman).
> Now one way to avoid this issue would be to let web servers send a
> default content-type / mimetype. However the W3C Authoritative Metadata
> standard, explicitly says this shall not happen.

No, on both counts. First, sending a default type doesn't avoid the issue;
it just encourages browsers to sniff whenever it sees that default type
(even if it wasn't set by default). We get silly things like


Defaults were abandoned specifically because it results in this security
issue becoming worse, not better.

Second, the authoritative metadata finding is not a standard -- it is a finding --
and it has nothing to do with a specific server owner's decision to apply a
default type to a specific set of resources. That's just configuration.
It is about the defaults chosen by server software developers (like me).

> The problem is like this:
> * A web application allows uploading any kind of "unusual" file type
>  that is not part of the server's mime.types. (The mime.types is in no
>  way standardized and differs significantly between distros, so there
>  can be practically no expectaiton on what that exactly means.) Let's
>  use a fictional file format .aaa as an example.

mime.types is not the only way to set media types on the server.

> * The web server will either guess the content type on its own or send
>  it without a content type and then the browser will guess the content
>  type. Both are bad. (Some web browsers - notably Edge+Firefox will
>  even guess the content when the "X-Content-Type-Options: nosniff"
>  header is sent, because that originally was only designed for .js
>  and .css files and thus won't prevent HTML sniffing.)
> * An attacker can upload a file example.aaa that contains html code and
>  javascript.
> * Calling that file will execute the javascript - you have an XSS.

I believe that browser good practice should be to disable such scripting
whenever the browser sniffs a type. Some people disagree. In any case,
that is a self-inflicted wound.

> This is a tricky to avoid issues. A web application like wordpress can
> hardly do anything about it (except maybe not allowing uploads of any
> "unusual" file types, but as written above, this is hard to define).

It can do anything it wants about it, including setting a default type for uploads
that prevents script embedding from being executed.  A web application is not
a general-purpose server.

> Now the safest way for a server to prevent this would be:
> a) don't guess content types.
> b) send a "safe" content type (e.g. application/octet-stream) for each
> file that has no extension that can be assigned via mime.types.
> Now the Authoritative Metadata standard says this SHOULD NOT happen:
> "Good Practice
> Server software designers (implementers) SHOULD NOT specify default
> representation metadata, such as media type, character encoding, or
> content language, within the standard configuration shipped with the
> server.

Apache httpd (or similar) != Wordpress (or similar)

> Instead of specifying a default for metadata, it is better for
> representations to be sent without that metadata. That allows the
> recipient to guess the metadata instead of being forced to either
> accept incorrect metadata or be tempted to violate Web architecture by
> ignoring it."
> In Apache this even led to complete removal of that option, going even
> a step further (not just not doing this by default, but actively
> removing any way for users to do this).

No, we removed the functionality of the old DefaultType configuration because
we can't change configuration files on updates.  A user can easily set the type
by default per location using ForceType:


> Contrary to that Nginx sends a
> default content type.

Nginx does not comply with HTTP/1.1, let alone TAG findings.

> I don't see any good justification for that option. It says "That
> allows the recipient to guess the metadata instead of being forced to
> either accept incorrect metadata or be tempted to violate Web
> architecture by ignoring it." But that's not a good thing: It's a
> security risk.

No, the security risk is executing untyped content.  It's a well-known risk
and is supposed to be addressed by the mimesniff spec.

> The whole document doesn't mention XSS or Cross Site Scripting, so I
> wonder if this has been considered in any way. I'm writing you to
> hopefully better understand why that decision was made and what the
> reasons were. As far as I see it there's a security flaw and one of the
> most obvious and likely robust fixes is forbidden by a standard without
> any good justification. I think the standard should be changed.
> [1] https://www.w3.org/2001/tag/doc/mime-respect#reducing-inconsistency

Yes, it was considered, as were all of the alternatives.  The security risk is in
sniffing, not in failing to set a default type.  Setting a default doesn't change that
unless the user agent doesn't believe it is a default.


Received on Friday, 11 January 2019 21:23:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:17 UTC