Tag Info

Hot answers tagged

14

I have some suggestions: Use a separate domain. Host the images on a separate domain that is used only to host user-provided images. This will ensure that many browser-level attacks can have only limited effects. For instance, suppose the user's browser is vulnerable to content-type sniffing attacks, so it is possible to upload an image that some ...


11

No, you shouldn't reply the user-supplied MIME type to the user. The simplest attack that you're exposing your users to would be to upload text/html file with arbitrary Javascript code e.g. in [script] elements. Users given the uploaded file URL would have the Javascript executed, resulting in XSS. This can be somewhat mitigated by serving the files with ...


8

Warning. The steps you describe are not enough to be safe, if those files are available from your servers. Explanation. Because browsers do content-sniffing in a variety of circumstances to guess at the appropriate MIME type, there are a variety of subtle cross-site scripting attacks that remain possible. The general category is sometimes known as ...


8

Much more common than a buffer-overflow type bug that @Zian mentions (though I think there was a WMF vuln of this sort in Windows as recently as 4-5 years ago), is something like GIFAR (also search on SO): a file that is both a valid image file (e.g. GIF), and a valid ZIP file (e.g. JAR (compiled java bytecode)). This is possible because of the way these ...


7

It must be noted that a file does not have an inherent "content-type" per se. A file is a bunch of bytes, and has a name. When you download a file from a Web server, the server infers a content-type (such as "application/pdf") from whatever clues it can find, mostly the so-called "extension" (the few letters at the end of the file name; e.g. ".pdf" is ...


7

The short answer: It is not safe. Allowing the user to specify the MIME type and the contents of the file is a self-inflicted XSS hole. A malicious user Mallory could specify the MIME type text/html, and provide a HTML document that contains malicious Javascript. When you serve that document to another user Alice, Alice's browser will execute the ...


7

The reason PDFs are preferred isn't security so much as a combination of technical capability and user expectation. The security of PDF and Word read only modes is about the same (which is to say, not very good, but good enough to prevent casual use.) Both files require a viewer on the other side, and there is both a Word and PDF viewer app for free, while ...


6

Typically the problem is not due to uploading, but hosting and same-origin/malware issues. Imagine the following scenario: Alice uploads a file which is served from https://example.com/alice/foo. Bob uploads a file which is served from https://example.com/bob/bar. Charlie downloads .../alice/foo, and later downloads .../bob/bar. Alice and Bob are ...


6

PDF's can be locked to prevent editing. Docx can be protected. html - not so much. Sure, there are ways of getting round even the best copy protection, up to and including taking screenshots or even dictating the comment, but protecting PDF's pretty much works. At least in a business environment. I don't think that is why tech people think pdf is better. ...


6

Typically the "insecurity" of files comes into play when they are accessed, not just by having them downloaded. Downloading a file unopened and having it pwn your computer is the stuff of Hollywood and science fiction (as far as I know, though there may be research into this too). Thus, to understand the problem, the real question is not about the file ...


5

The best way to open such files is by running them inside a sandbox. I would suggest a virtual machine. Regarding which kind of files are safe, one can make two distinctions. In practice, files like zip, txt, jpg, png, etc are safe. Files like .exe, .msi, .com, .bat, .vbs, etc etc are unsafe. However, there is one big issuge with "safe" files, it is ...


5

I assume when you say "image" you mean something like a JPEG or a GIF. The answer is that older software has bugs such that when they display the image, they can get confused. For example, images have comment fields inside them that are usually not displayed, but can contain things like the GPS coordinates of the iPhone camera that took the picture. Typical ...


5

One possible solution would be to re-write the file as a simple known format before displaying the image on the site. e.g. someone upload an image (possibly with an exploit), immediately, the server read the image in a secure way and write a new image. If the program/script that used to read the uploaded image read only color data, the new image can only ...


5

Well, that's really a question for the makers of your email client to answer, but in general if software blocks every file attachment of a particular type then it is for one of four reasons: The file is directly executable, and so might have a virus in it The file is indirectly executable - e.g. a Word document might contain Macros that execute when you ...


5

It sounds like you are concerned about viewing documents from an untrusted source (e.g., concerned about the risk that a malicious document might exploit a vulnerability in your PDF viewer, or in Word, or the like). That's a reasonable concern. If that's the concern, one way to mitigate it is to use Google Docs to view the document. Google Docs provides ...


4

As a site owner, there is only so much you can do about it. The primary responsibility for protecting users from malicious documents lies with the software vendors who make the document viewers (e.g., Adobe, Microsoft, and potentially browser vendors). They are the ones with the opportunity to best help their users; your leverage is more limited. That ...


4

The screenshot indicates that the Windows Attachment Manager has identified what it considers a possibly dangerous file from an external source and marked it. See http://support.microsoft.com/kb/883260 for information on what the Attachment Manager is and how to configure it. The Windows Attachment Manager will mark many types of files that could possibly ...


3

I'd think that's adequate. However, I'd still never put uploaded files in a directory that can be directly accessed through the webserver: have users access the files through a download script. This way, even if someone manages to upload something executable, it will not get executed. Be very careful when calling "file" by the way, if the filename the user ...


3

From comments to question I understood that one might be interested to get into details of executable images (oops, "image" collides with a copy of a disk, let say, pictures that are excutable/runnable scripts or programs) which look to humans as images (pictures) and to computer as executable scripts (programs): Video DefCon 15 - T312 - The Executable ...


3

Probably not safe. There are various attacks that trick the content type sniffer into believing a file is the wrong content type. Here's a particularly infamous example: http://adblockplus.org/blog/the-hazards-of-mime-sniffing The suggestion of the previous poster is good for protecting your server from malicious scripts: move uploaded files outside of the ...


2

I guess it depends on perspective? From the end-user standpoint, to protect against exploits (esp memory/buffer overflows) from images or any other source (again, that exploits buffer overflow vulnerabilities) would benefit from making sure memory protection features are fully enabled. In Windows, mechanisms like DEP (based on NX/XD) and ASLR among others ...


2

When I've had to tackle this before I've converted the file from it's source format into another and sometimes then to a third format. If Open/LibreOffice supports your document format you could just call it with --convert-to pdf. Then you can take that PDF and manipulate it further, eg using ImageMagick: convert source.pdf source-page-%d.jpg convert -page ...


2

To answer your question directly, PDFs are less secure because Adobe has been plagued with security problems. It is 'easy' to embed malicious code into a pdf that Adobe Reader will not filter out. Other document formats (Word, etc) can have the same problems, but they tend to have ways to mitigate the problem (if you use the most up-to-date version of ...


2

PDF are much more portable than Doc(x) and HTML; at least, fonts usually come out the right size, contrary to what happens when trying to open a Word document in LibreOffice or another Word version or the supposedly same Word version but on another computer with a different OS version or distinct set of installed fonts. The same applies to HTML and the whole ...


1

It depends what you mean by "safer". With PDF you are be guaranteed that it will display more or less the same on any device regardless of screen resolution, viewer/editor used, etc. Also, users expect to open it with a viewer program rather than an editor, thus setting a certain expectation. So it is arguably the "safer" format in terms of presentation. ...


1

Regarding DW's answer: Optional: Use a separate domain to host file uploads. You could host the documents on a separate domain that is used only to host user-uploaded documents. This will limit the impact of some browser-level attacks, such as content-type sniffing. However, this does not defend against code-injection attacks that exploit a vulnerability ...



Only top voted, non community-wiki answers of a minimum length are eligible