Re: Invisible characters must be specified to be visible in security-sensitive situations

The suggested filename has no real importance, it could be garbage,
Displaying it exactly has no importance. What is important is to display
the MIME type (which is transmitted separately of the filemane, and
frequently as well without the filename, a browser trying to infer a
suitable filename from the URL, but it should respect the MIME type).

The acceptable MIME types (and especially here when they are executable
like here a javascript), should be clearly identified, and then the
file-extension removed from what is displayed when it matches the MIME
type. With these, the user would not be confused by the presence of a Bidi
override control
So.
  "photo_high_re"+<U+202E>+"gnp.js"
becomes the text field (to embed in an isolate like <bdi></bdi>)
  " <bdi>photo_high_re"+<U+202E>+"gnp</bdi> (text/javascript)"
rendered as
  "photo_high_regnp" (text/javascript).
The browser may also be smarter by describing it as an executable script.
But here in an alert box, where it detects a potential harmful content, the
suggested filename to display should be simply filtered from these Bidi
controls, and the suggested file extension removed and replaced by the
default extension for the MIME type outside the isolate). The user would
then see;
  "<bdi>photo_high_regnp</bdi>.js" (text/javascript)
where the suggested filename was altered (in such alert, the suggested file
names should also be truncated to a maximum limit and an indication of the
truncation before the replaced extension, such as:
  "<bdi>photo_high</bdi>[...].js" (text/javascript)

As well the generic icon used is not enough descriptive and counter
productive as the user may think the icon is a preview of a PNG image,
that's why the MIOME type should be clearly exposed.

2018-02-15 23:33 GMT+01:00 Oren Watson via Unicode <unicode_at_unicode.org>:

> https://securelist.com/zero-day-vulnerability-in-telegram/83800/
>
> You could disallow these characters in filenames, but when filename
> handling is charset-agnostic due to the extended-ascii principle this is
> impractical. I think a better solution is to specify a visible form of
> these characters to be used (e.g. through otf font variants) when security
> is of importance.
>
Received on Thu Feb 15 2018 - 18:17:52 CST