require audio content-types for <audio> sources (similarly <video> and other subresources?)




DOM: Security
2 years ago
2 years ago


(Reporter: Abdulrahman Alqabandi, Unassigned)


50 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [domsecurity-backlog2])



2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce:

I managed to create an mp3/html polygot and it doesn't look like firefox checks content type of served file which may cause security issues to some websites.


<audio controls src="data:text/html;base64,//MUxHNtYWxsZXN0LW1wMy1ieS1AcWFi//MUxCc+Ij4vPjxzdmcvb25sb2FkPS8q//MUxCovYWxlcnQoJ0BxYWInKTs+YW5k//MUxA==" id="qaz"></audio>
	alert(1);//proof its playable


Actual results:

Visisting the source of the 'mp3' (right click + copy source) will execute html, also, when saving the 'mp3' it will be saved as an html which could trick some users into executing arbitrary html on local disk.

Take the example of an mp3 hosting website. If the polygot is allowed to be uploaded and served using an audio tag its possible this unexpected behavior in firefox could pose a security risk to some users.

Chrome does not allow mp3 files to be served with an html content type

Expected results:

The audio tag should simply block non-audio content types when being served as its observed with google chrome.

Comment 1

2 years ago
After some pondering on this, this relies heavily on a servers misconfiguration. So I dont think firefox is to blame if some website serves mp3's with an html content type.
Request to remove security tag. 

But there still needs some fixing. even if we remove the content type from the data url 'data:;base64,...etc' so long as the data returned is somewhat valid mp3, it will go through.
On the whole for sub-resources Firefox trusts the HTML context of a load and ignores the MIME type, because in the past servers were commonly misconfigured.

We are starting to implement the X-Content-Type-Options: nosniff "standard", but have not yet gotten audio hooked into that (bug 1289056). That bug is not directly relevant because your testcase doesn't send that header, but a concerned site that allows uploads might.

How strict a site should be in the absence of the XCTO header is still being discussed.

A more worrying scenario would be if the Content-Type said audio/something and we opened it as an HTML web page--but we don't as far as we know. Sites are unlikely to allow uploads of text/html data, but might allow uploads of MP3s served with the correct MIME type.
Group: firefox-core-security → dom-core-security
Component: Untriaged → DOM: Security
Product: Firefox → Core
This is a valid enhancement request -- to essentially enforce "nosniff" behavior without having to have the header, in places where we can get away with it. When we enforce nosniff for these types we can add in telemetry and find out if the occurrence is rare enough to get away with doing so. The fact that Chrome does means we ought to be able to do so.
Group: dom-core-security
Severity: normal → enhancement
Depends on: 1289056
Ever confirmed: true
Priority: -- → P3
Summary: Mp3 can be served with text/html content type → require audio content-types for <audio> sources (similarly <video> and other subresources?)
Whiteboard: [domsecurity-backlog2]
You need to log in before you can comment on or make changes to this bug.