Hacker News Reader

Comment by nine_k | Hacker News Reader

It could maybe potentially be exploited in a very interestingly crafted email, where there's link to download something (e.g. the source tarball, or a build artifact) with an URL containing the username, or being otherwise close by, so that the downloaded file would be interpreted differently. But I'm not creative enough at this hour to suggest a working exploit.

View on HN

I suspect a case of impersonating a user which doesn't have the suffix. Ex: create user "toto.mov" to takeover some resources of user "toto".

Maybe it's something to do with a MIME sniffing attack. The user profile URL may be detected as a different MIME type by the browser based on the extension: https://gitlab.com/myname.js

I'm not sure how one could exploit it though...

AFAIK in MIME sniffing IE guessed file type based on its content [1], not URL. And given that IE is rarely used nowadays not sure if it still relevant.

[1]: https://docs.microsoft.com/en-us/previous-versions/windows/i...

Update: tested this link in FireFox 92 - it still performs sniffing in 2021: http://www.debugtheweb.com/test/mime/script.asp (based on the content, not extension)

I've played with this before. A correctly implemented mail library should handle e.g., subject lines that contain SMTP control characters. I developed a lengthy repro for an email parsing issue in an ancient version of some java email library that contained a truely horrendous parser, only to find out that the library had been updated internally recently :-)

MIME types are used all over the place:

1) web servers, browsers, proxies 2) graphical os shells 3) email

every file a webserver returns has a mime type in the header, and that is how the browser knows how to present it.

Even webserver returns a mime, browser may sometimes still ignore it and guess it themselves, because server may be wrong. Unless the server ask them `absolutely don't do it` via the header. a.k.a. `X-Content-Type-Options: nosniff`

But even there is a header for that, there will still be situations that clients don't care and guess it themselves (probably because software is too old or other reason).

Correct. You want to set Content-Type and X-Content-Type-Options.

The story is that in some cases, Internet Explorer could be tricked to ignore the Content-Type header. Instead of fixing the core bug, Microsoft decided to add a header (presumably, they didn’t want to break existing websites). A decade later, people discovered two ways to bypass X-Content-Type-Options. This time, Microsoft fixed the core issue instead of adding X-Content-Type-Options-For-Reals.

Actually when I reported security issues with XCTO:nosniff to Microsoft the answer was something like "well... we don't care, but you can hope that with Edge going to chromium engine things will change". Firefox fixed it eventually.

FWIW background https://www.youtube.com/watch?v=8t8JYpt0egE

> could be tricked to ignore the Content-Type

I think even browser nowadays still do it. A file in <script src="" /> will be treated as script even mime is wrong. A file ended with .mp4 will be play as video even it says it is a text/plain file. Browser guess mime from contents at many places, just you may not notice it.

unless XCTO is set

The ticket here reveals some blacklisting of known file extensions (attached to a know list of MIME type), not MIME types directly.

Reply on news.ycombinator.com