3 ms·

Some application security thoughts for serving untrusted content. Not all are required but the main thing is that you don't want the user to be able to serve h

Some application security thoughts for serving untrusted content. Not all are required but the main thing is that you don't want the user to be able to serve html or similar (pdf, SVG?) file formats that can use your origin and therefore gain access to anything your origin can do: - serve on a different top level domain, ideally with random subdomains per uploaded file or user who provides the content. This is really most important for serving document types and probably not for images though SVG I think is the exception as it can have scripting and styling within when loaded outside of an IMG tag - set "content-security-policy: sandbox" (don't allow scripts and definitely don't allow same origin) - set "X-Content-Type-Options: no sniff" - disabling sniffing makes it a lot harder to submit an image that's actually interpreted as html or js later. Transforming the uploaded file also would defeat most exploit paths that depend on sniffing the content type.

bawolff 2y ago
Pdf isnt too bad, it has javascript but generally is sandboxed so you cant do anything bad with it. SVG is basically the same as html, and you can do standard XSS stuff. Hosting on separate domain (not just subdomain but actual separate domain) is a must if you allow formats like svg, and a good idea generally.
technion 2y ago
As a side issue here I can't believe sniffing is still the default. From basically the day it existed it's been considered a best practise to send that header with every request, because there might be a vulnerability introduced otherwise . I've never heard of anyone relying on it. Why can't modern browsers flip the default on this internet Explorer era magic footgun?
- bawolff 2y ago
  > As a side issue here I can't believe sniffing is still the default It isn't the default in modern browsers, or at least not in the sense you mean. The header still controls some things, but even without it, browsers will not sniff something served as content type image/png as html or anything like that. How modern browsers interpret that is different than IE.
  - dgoldstein0 2y ago
    I think it's still the default with text/plain. Haven't verified that though

bawolff 2y ago

Pdf isnt too bad, it has javascript but generally is sandboxed so you cant do anything bad with it. SVG is basically the same as html, and you can do standard XSS stuff. Hosting on separate domain (not just subdomain but actual separate domain) is a must if you allow formats like svg, and a good idea generally.

technion 2y ago

As a side issue here I can't believe sniffing is still the default. From basically the day it existed it's been considered a best practise to send that header with every request, because there might be a vulnerability introduced otherwise . I've never heard of anyone relying on it. Why can't modern browsers flip the default on this internet Explorer era magic footgun?

bawolff 2y ago
> As a side issue here I can't believe sniffing is still the default It isn't the default in modern browsers, or at least not in the sense you mean. The header still controls some things, but even without it, browsers will not sniff something served as content type image/png as html or anything like that. How modern browsers interpret that is different than IE.
- dgoldstein0 2y ago
  I think it's still the default with text/plain. Haven't verified that though