> I'm not sure what the security implications are.

You can use this technique to phish signatures. Send someone a document that reads "X" in format A and "Y" in format B. The victim signs file.A thinking they are endorsing X but you can plausibly claim that they signed file.B (because it's the same file) and hence endorsed Y. This is why digital signature standards need to include meta-data, e.g.:

https://github.com/Spark-Innovations/SC4/blob/master/doc/fil...

Scroll down to "bundle files"

> but you can plausibly claim

And anyone else can plausibly claim that you carefully forged a file to get a victim to sign it -- the signature will be of the whole file, not just a single view of it.

But that said, you shouldn't sign binary files unless you have a reasonable understanding of what is in it (or trust the party presenting it to you).

> And anyone else can plausibly claim that you carefully forged a file to get a victim to sign it

Yes, of course, but by the time someone realizes this the damage may already have been done.

> you shouldn't sign binary files

There are a lot of things that people shouldn't do that they do nonetheless.

there are websites where you can upload files such as images, but they filter html for security reasons. if you can present that html to someone (eg. through deeplinking an iframe to the document), it could contain (or load) javascript that runs in the context of that site...

This is why it's important to correctly set the Content-Type header when serving files. Also why it's a good idea to have user-uploaded content served from a separate domain.

Some browsers might try to sniff the mime type, so an additional header would help : "X-Content-Type-Options: nosniff"[1]

1. https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-...

Thanks! I remembered something like that existing but I couldn't remember the header name :)

Please elaborate on the part about UCG from a separate domain. Why is this?

If someone uses this trick to upload a PNG like this to your server, and that person is tricked into running it as HTML, then that HTML has access to your cookies and can make make AJAX requests (circumvent same origin protection).

If user content is on a separate domain, they can't do that.

Also fishing is a lot easier when you're on the real domain...

Sorry, didn't see this comment earlier. GitHub's blog post on why they did this gives some good insight.

https://github.com/blog/1452-new-github-pages-domain-github-...

file -k may give different results, but binwalk [0] is probably a better choice

[0]: http://binwalk.org/