315

Client side validation The validation code you have provided is in JavaScript. That suggests it is code that you use to do the validation on the client. Rule number one of securing webapps is to never trust the client. The client is under the full control of the user - or in this case, the attacker. You can not be sure that any code you send to the client ...


76

The biggest concern is obviously that malicious users will upload things that are not images to your server. Specifically they might upload executable files or scripts which they will attempt to trick your server into executing. One way to protect against this is to make sure that the files are not executable after you move_uploaded_file in PHP. This is as ...


52

There used to be a "vulnerability" where the image could send a HTTP 401 Unauthenticated response, which would trigger a login screen for the user. If you set this as forum avatar, it would spawn a login popup for anyone visiting a page where your avatar appears. Lots of people will then attempt to log in with some username and password combination, probably ...


49

There are basically two main ways an uploaded file can be harmful: by being executed (as a script or binary) or by being run/used in an application and abusing an exploit in it (e.g. an uploaded MP3 which is then opened by a specific player, abusing a known weakness in it). In other words, it all depends what happens with the file after uploading. If ...


36

First off, if someone exploited a file upload function, ensure that you're verifying the file on both the client and server. Bypassing client-side JavaScript protection is trivial. Second, ensure that you go through and implement these ideas from OWASP. That should cover most of your problems. Also ensure that you don't have any other unpatched flaws on ...


33

It's very dangerous, because you are allowing to someone to upload PHP file with unknown code and unknown intentions, so if you need this functionality as part of your web site, you should harden your server, for example: Set a only one directory to upload PHP files from users, you should apply right user permissions (read, write or execution) for this ...


29

If you allow somebody to upload and execute a PHP script on your server, you effectively give this person the right to do whatever he or she could do, if she had ssh access with username/password for process the PHP script runs as. So, if the person in question would run the script through Apache, the person could do anything the Apache user on your server ...


26

It is super-important to note here that PHP was designed to be embedded in other content. Specifically, it was designed to be embedded within HTML pages, complementing a largely static page with minor bits of dynamically updated data. And, quite simply, it doesn't care what it's embedded in. The PHP interpreter will scan through any arbitrary file type, ...


25

To me it sounds like you are about to shoot yourself in the foot. Letting people you don't trust upload and run PHP on your server is extremely dangerous. Here are some things an attacker could try: Run batch commands taking over your webserver. It can then be used as a staging ground to attack other servers from within your network. Read files containing ...


23

Background. X-Content-Type-Options: is a header that is designed to defend against MIME content-sniffing attacks. MIME content-sniffing attacks are a risk when you allow users to upload content (e.g., images, documents, other files) to your website, where they can be downloaded by other users. As @Rook says, this has nothing to do with eavesdropping/...


23

You can disable PHP in your upload directory by .htaccess so your server won't execute any PHP code in the directory and in its subdirectories. Create a .htaccess file inside your upload directory with this rule: php_flag engine off Please note that the .htaccess rule will work only if your PHP server is running in mod_php mode. Edit: Of course, i forgot ...


22

You want PHP's Fileinfo functions, which are the PHP moral equivalent of the Unix 'file' command. Be aware that typing a file is a murky area at best. Aim for whitelist ("this small set of types is okay") instead of blacklist ("no exes, no dlls, no ..."). Do not depend on file typing as your sole defense against malicious files.


22

It is not clear from your description why you want block these files exactly. I see the following possibilities: You want to block files that might infect the server itself. Unfortunately this can be about anything: shell, perl, python, awk, ... and of course compiled binaries. But to get these files executed without explicitly calling them with an ...


21

The most common solution for this kind of issue is to make sure the stored file is not accessible by the web server. One simple way to do this is is to store the file in a database and never save it to the disk. You need to be careful not to create some kind of XSS though: do not allow the file to be linked to directly or, ideally, downloaded. If you need ...


20

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 browsers ...


19

Could an SVG be constructed in such way, that when reading meta data it makes the server unresponsive. and could be used as DoS attack on the server? What do you mean by metadata? If you are after width and height, you would have to parse the SVG files at least partially to get it; there's no shortcut of reading a few bytes from the header like there is ...


18

With plain FTP the credentials are passed in plain and thus can be easily sniffed. Also, the files are not only send in plain but they are also not protected against modifications, i.e. an active man in the middle might change the files on the fly. Insofar the risks are similar to plain HTTP, i.e. it might be fine within a trusted network but is a bad idea ...


17

The IMG tag will attempt to interpret the data as an image, so Javascript won't be executed. It will be possible to send an image that, once decoded, will require enormous amounts of memory ("PNG bomb"), and it is possible that the graphic routines themselves are vulnerable to malicious content (a carefully crafted image that, when decoded, triggers ...


17

While there are sites that allow you to run PHP code on demand (i.e. 3v4l), they severely limit what you can do and jump through some major hoops to do it safely I use a setup where scripts are executed in a small virtual machine. For security reasons this machine has no network and only a minimal filesystem. Scripts are executed by a daemon (written in ...


16

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 content-...


14

One possible path would be to try and get it to be included somehow. A lot of add-on frameworks can run an arbitrary PHP code file. If the attacker was able to find such an add-on framework, they could give it the path to the file and it would be executed as PHP regardless of the file extension.


14

Short answer: there is necessarily a public/private key pair on the server. There may be a public/private key pair on the client, but the server may elect to authenticate clients with passwords instead, SSH is a generic tunnel mechanism, in which some "application data" is transferred. One such application is the "remote shell" which is used to obtain an ...


14

Don't block any specific MIME types. Block any kind of execution of the uploaded files. A simple way is to store uploaded files outside of the web root and serve them via scripting. If that's not possible, store files in a subdirectory and configure your server not to execute any scripts in that directory. Remember to do this for any scripting language that ...


13

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 ...


13

A null byte is a byte with the value zero, i.e. 0x00 in hex. There have been security vulnerability related to null bytes. These occur because C uses null bytes as a string terminator. Other languages (Java, PHP, etc.) don't have a string terminator; they store the length of every string separately. Now, consider a Java web application that accepts file ...


13

Regardless of the placement of the PHP code [...], the website just shows the image file when I open it after uploading Yes, that is how it should be. The server would be seriously vulnerable if it would interpret .jpg files as .php files depending on the content instead of the extension. So in such a case, what should be done to execute the file as ....


12

A lot depends on which unix like environments you're talking about. Linux probably has the best support for AV engines - but the open-source ones will run on any posix environment. ClamAV FRISK F-Prot Kaspersky OpenAntiVirus.org ScannerDaemon MKS AntiVirus Sophos Sweep Symantec AntiVirus Engine Trend Micro Personally, I'd go for Clam Av. Not only has it ...


12

One area where ZIP files could present a risk to the application the zip bomb attack. this occurs where an archive is constructed in such a way that when it's opened it consumes a large quantity of space on the server potentially causing it to crash. It might be possible to mitigate this issue by opening zip files on a dedicated filesystem and then ...


12

Files have signatures or "magic numbers" embedded in them, usually near the beginning of the file. libmagic is a library which extracts a files signature and looks it up in a signature database. This is the way Unix type systems determine file types i.e. if you save a text file without an extension on Linux it will still automatically open with a text ...


12

No. Renaming a file doesn't increase security. He says to me, that by making all files images no harm can be done to the server. for example evilscript.evil would become evilscript.png When you rename evilscript.evil to evilscript.png you don't turn it into an image. You just change its name. Generally, a file name isn't relevant. It is just a name ...


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