Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicitly state that UA can reject file based on its type #127

Closed
mgiuca opened this issue Sep 27, 2019 · 6 comments
Closed

Explicitly state that UA can reject file based on its type #127

mgiuca opened this issue Sep 27, 2019 · 6 comments

Comments

@mgiuca
Copy link
Collaborator

mgiuca commented Sep 27, 2019

With examples to prevent sharing of executable files.

Could be based on extension, MIME type or contents.

@mgiuca
Copy link
Collaborator Author

mgiuca commented Sep 27, 2019

It actually does have this (search for the word "block").

But it needs to change to split it out from the user activation check, and move it into the "in parallel" steps, so it can be done async.

@marcoscaceres
Copy link
Member

Over on the gecko side, we've been considering the following attack:

const evil = new File([...evilBytes], "cat.exe");
navigator.share({files: [evil], title: "Cute cat image!"});

In order to mitigate the above, we should require each File have both type and a filename with an extension, and that the type must match an expected extension. We should have a limited list of recommended sharable types/extension combinations.

This also allows us to avoid having to do content type sniffing, although that could be done as well.

So, concretely, we should replace:

If a file type is being blocked due to security considerations, return a promise rejected with with a "NotAllowedError" DOMException.

With a lookup-table for allowed MIME + extensions-list combinations.

@mgiuca
Copy link
Collaborator Author

mgiuca commented Oct 27, 2020

TPAC 2020: Resolved to make a change to the spec to let browsers determine their own rules for blocking based on file type.

We can discuss further having a formal list of allowed / blocked types, but no consensus on that.

@NotWoods suggests https://html.spec.whatwg.org/multipage/links.html#allowed-to-download as a starting point.

@marcoscaceres
Copy link
Member

The HTML suggestion relates to the download= attribute, but in our case we use Permissions Policy to enable the functionality. However, I adapted the text "Optionally, the user agent may return false, if it believes doing so would safeguard the user from a potentially hostile download." and added it to 6c0a9f5.

@marcoscaceres
Copy link
Member

List of extensions / types from Chromium : https://docs.google.com/document/d/1tKPkHA5nnJtmh2TgqWmGSREUzXgMUFDL6yMdVZHqUsg/edit

@marcoscaceres
Copy link
Member

closing as handled by 6c0a9f5 for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants