We do not want to santitize them with DOMPurify, as an attached file should
be returned exactly as it has been attached by the creator. And sharing HTML files
is IMHO a legitimate use case.
However, opening these in a new tab can result in (JS) code execution.
Yet again, opening a "bigger" preview for some file types like images or videos
is also a valid use case, which also should not be broken. That's why this is not done
in alll cases, but some mime type filtering still exists.
I also looked into whether a blocklist (for HTML and SVG) would make sense, but really
you cannot possibly define an exhausive list of "unsafe" mime types: https://security.stackexchange.com/a/167853/91425
That's why I use a quite strict allowlist approach here.
I skimmed https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/MIME_types/Common_types
for what could be common use cases/mime types, people _may_ actually want to get
rendered and this is the result.
Thus I am quite confident this patch does not introduce such a big "breaking change"
(in UI behaviour), but people best do not notice it.
- Load-confirm modal: focus primary action on show
- Email-confirm modal: focus UTC button on show (safer default)
- Update SRI for js/privatebin.js in Configuration.php
Fixes#1801
IMHO this check is actually necessary, as we do call the function with an empty argument. So we need a guard there, but we could simplify it a bit, by making the argument an empty array by default. I still kept the check for undefined (line 3249, first check) in case the caller passes us an undefined variable.
See: https://github.com/PrivateBin/PrivateBin/security/quality/rules/js%2Funneeded-defensive-code - Copilot suggested to simply remove the if-condition and its else block, which I think is wrong.
- added missing exception doc blocks
- introduced exception type that translates message during construction
- catch explicit exception types where possible
