Add check in frontend implementation for `acceptedFileTypes` violation

[mshedsilegx]

1.9.0-9feecf3 acceptedFileTypes: 'image/,text/,application/pdf'

[Luzifer]

As the documentation states:

# Pay attention this is NOT suited as a security measure as this is
# purely a frontend implementation and can easily be circumvented. The
# client tool does NOT check those file types and the server is not
# able to check them as it never sees the real content of the file.

This is not a security feature. Nothing can stop an user to attach other files than the ones you put into the attribute. The attribute only configures the accept attribute of the HTML file selector. If you change the "Custom Files" option of the file selector (might look different depending on your system) to "All Files" you can select any file you want to:

See this as a "suggestion" to the browser which files you want the user to choose. The browser configures the system file selector with those types but it can be ignored.

To securely limit the files you would need a server-side-check which is not possible as the server never sees the file in an unencrypted state. Even if I would try to parse that list in the frontend JS myself and match the file type (or the name) the browser gives me to the list this still does not guarantee anything.

Even if I would do this in the frontend JS and the OTS-CLI util you simply can write a fairly simple script to attach an executable to a secret.

[mshedsilegx]

OK, noted.

[mshedsilegx]

I was thinking of the following. Is is possible to have an implementation of a forbidden extension that would mimic the experience of a large size issue like below ?

Since you can do a validation test on the file size, why not on the file extension ?

[Luzifer]

Well also the file size is not a security check and you really should set a max-body-size in the webserver. You cannot trust any check done in the frontend. Like I said above: I could parse that list in the JS code and then try to match the file to it (given I get correct information which itself is not guaranteed especially with more exotic file types) but what does it give? A false sense of security.

The CLI can upload a 1GiB file containing a giant virus collection… If we stop that in the browser and the CLI, the attacker will use a custom shell script. We lost.

I'm fully aware how security works and there is no security at all but doing checks in frontend is just like asking a thief not to steal your diamond laying in front of them while you drive to work…

The question is: Is it worth the effort implementing the parser and the matcher when it doesn't prevent anything?

[mshedsilegx]

I understand your arguments. I think it is OK to treat approved extensions as not a security check. It is more a business control, whose scope is only UI and CLI, not API for the reasons you stated. Just a simple list of allowed extensions as a property, and a file name check to validate the extension. If not in the list, return a blocking error message like the one above.