Copyright: Attribution, allow others to create paper-based, and must distribute paper (based on the original license agreement with the same license Creative Commons )
In order to allow the end user to upload files to your website, like a malicious user to endanger your server to open another door. Even so, in today's modern Internet Web application, it is a common requirement, because it helps to improve your business efficiency. In Web applications like Facebook and Twitter social networks, allowing file uploads. Let them in the blog, forums, e-banking sites, YouTube and Enterprise Support Portal, end-users and give the opportunity to the employees to effectively share files. It allows users to upload pictures, videos, avatars and many other types of files.
The more features available to end users, Web application attacks and the risk the greater the chance that this feature will be exploited by malicious users to obtain rights to a particular website, or server-threatening possibility is very high.
When testing several Web applications, we note that a considerable number of well-known Web applications do not have secure file upload form. These vulnerabilities can easily be exploited, we can access these servers hosting Web applications to the file system. In this article, we will show you 8 kinds of ways, we encountered security file upload form. At the same time, we will also show a malicious user can easily bypass these security measures.
Case 1: There is no verification of a simple file upload form
A simple file upload form typically contains an HTML form and PHP script. In the form of an HTML form presented to the user, and the code required PHP script file upload function included. This form and PHP script Here is an example:
HTML Form:
<form enctype="multipart/form-data" action="uploader.php" method="POST">
<input type="hidden" name="MAX_FILE_SIZE" value="100000" />
Choose a file to upload: <input name="uploadedfile" type="file" /><br />
<input type="submit" value="Upload File" />
</form>
PHP Code:
<?php
$target_path = "uploads/";
$target_path = $target_path . basename($_FILES['uploadedfile']['name']);
if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path)) {
echo "The file " . basename($_FILES['uploadedfile']['name']) . " has been uploaded";
echo "There was an error uploading the file, please try again!";
} else {
}
?>
When the POST request is received PHP and encoding type multipart / form-data, it creates a temporary file name random temporary directory (e.g., / var / tmp / php6yXOVs). PHP will be filled with information on the global array $ _FILES upload the file:
$ _FILES ['UploadedFile的'] ['名称']：在客户机上的文件的原始名称
$ _FILES ['UploadedFile的'] ['类型']：文件的MIME类型
$ _FILES ['UploadedFile的'] ['大小']：文件的大小（以字节为单位）
$_FILES ['UploadedFile的']['不对tmp_name']：上传的文件存储在服务器上的临时文件名。
PHP function move_uploaded_file move the temporary files to a user-supplied location. In this case, the destination is the root directory of the server. Therefore, URL files can be used, such as: HTTP: //www.domain.tld/uploads/uploadedfile.ext access. In this simple example, there are allowed to upload a file type is not limited, so an attacker can upload a PHP file with malicious code or NET, can cause the server to compromise.
This may seem like a very naive examples, but we have not encountered such a code in some Web applications.
Case 2: Mime type validation
Another common mistake when Web developers to ensure that the file upload form, just check the return mime type from PHP. When a file is uploaded to the server, PHP will set the variable $ _FILES MIME type [ 'UploadedFile'] [ 'type'] provided by the Web browser used by the client. However, the file upload form validation can not rely on this value. A malicious user can easily use scripts or other automated application that allows to send an HTTP POST request, which he sent a fake mime types of files to upload.
Case 3: limit the risk of expansion
In another example, we encountered a file upload blacklist approach, as a security measure. From the list of dangerous developers to develop collection, if you are uploading files included in the list, access is denied.
Use of dangerous file extension, one of its main drawback is that it is almost impossible to compile a complete list, including the names of all possible extensions attacker can use. For example, if the code is running in a managed environment, usually such an environment so that a large number of scripting languages such as Perl, Python and Ruby, the list can be endless.
A malicious user can easily bypass the checks upload a file named ".htaccess", which contains similar to the following line of code:
AddType application/x-httpd-php .jpg
The above line of code that indicates ApacheWeb server performs jpg images as if they were PHP script. An attacker can now upload a jpg file extension, which contains the PHP code. As the screenshot below, through a web browser requests a jpg file, which contains the PHP command phpinfo () function, it is still executed from the Web server:
Case 4: double extension (Part 1)
In this case the use of security policies and cases in three used very similar. Although replaced by a simple way of checking the file name extension, developers have by looking in the file name '.' Character and after the extraction point number string to get the file extension.
Bypassing the way to approach a little complicated, but still realistic First, let's look at how to deal with Apache files with multiple extensions of the Apache manual following paragraph stated:.
"File can have multiple extensions under normal circumstances the order of these extensions is irrelevant for example: if the file welcome.html.fr is mapped to the content type is text / html, the language is French, then the file will be mapped to exactly the same welcome.fr.html If the content is more than one extension is mapped to the same type of meta-information, that will be used far right, in addition to language and content encoding, such as:.. .gif MIME type is image / gif, .html MIME type is text / html, then welcome.gif.html MIME type will be text / html. "
因此一个名为 ‘filename.php.123’ 的文件将会被解释为一个PHP文件并被执行.这仅限于最后的那个扩展名(本例中是 .123)没有在web服务器的 mime-types列表中被指定.web开发者通常不会意识到Apache还存在这么一个 ‘特性’, 出于某些原因来说这可能非常危险.知道了这个以后,一个攻击者可以上传一个名为 shell.php.123 的文件并绕过文件上传保护机制.后台脚本将会计算出最后的扩展名(.123)并作出该扩展名并不在危险的扩展名列表内的结论.话虽如此,想要预防某恶意用 户可能会使用的所有随机扩展名来上传一个文件到你的web服务器上是不可能的.
案例5: 双扩展名 (第2部分)
一个更好的增强文件上传表单的安全性的途径就是白名单机制. 在本例中, 开发者定义了一个 已知/可接受 的扩展名列表并且不允许使用未在名单中指定的扩展名.
然 而, 在某些情况下该途径不会像期待的方式那样工作. 当 Apache 被配置为执行 PHP 代码的时候, 存在两种方式来实现该机制: 使用 AddHandler 指令, 或者使用 AddType 指令. 如果 AddHandler 指令被使用, 所有包含 ‘.php’ 扩展名的文件名(例如: ‘.php’ , ‘.php.jpg’)均被作为 PHP 脚本来执行. 因此, 如果你的 Apache 配置文件包含如下一行的话, 你可能很容易受到攻击:
AddHandler php5-script .php
一个攻击者可以上传名为 ‘filename.php.jpg’ 的文件并绕过保护机制, 然后执行其中的代码.
案例 6: 检查图片头部
当 仅允许上传图片的时候, 开发者通常使用 PHP 的 getimagesize 函数来检测图片的头部信息. 该函数在被调用时将会返回图片的尺寸, 如果图片经验证为无效的, 也就是说图片头部信息不正确, 则会返回 false 值. 因此一个开发者一般会检查该函数是否返回 true 或 false, 并且通过该信息来验证上传的文件. 所以, 如果一个恶意用户试着上传一个内嵌有简单 PHP shell 的 jpg 文件的话, 该函数会返回 false 然后他将不允许上传此文件. 然而, 即使这种方式也能被很容易的绕过. 如果一个图片在一个图片编辑器内打开, 就如 Gimp, 用户就可以编辑图片的注释区, 那儿就能插入 PHP 代码, 就如下图所示.
该图片仍然有一个有效的头部; 因此就绕过了 getimagesize 函数的检查. 从下面截图中可以看到, 当一个普通的 web 浏览器请求该图的时候, 插入到图片注释区的 PHP 代码仍然被执行了:
案例七：通过.htaccess保护上传文件夹
另一种流行的穿件安全的文件上传表单的方法是适用.htaccess保护好上传文件存放的文件夹。办法是限制这个文件夹里的脚本文件的执行。这种情形一下，一个.htaccess文件一般包含下面的代码：
AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi
Options –ExecCGI
上面的是另一种形式的黑名单，本身并不是很安全。在PHP手册中，move_uploaded_file一章中，有一个warning:若目标文件已经存在，则会覆盖原文件。
因为上传的文件能够而且会覆盖已经存在的同名文件，一个恶意用户很轻易就能用他自己修改过的.htaccess替换掉原来的。这使得他可以执行特定的将会帮助他危害服务器的脚本。
案例八：客户端验证
另一种在文件上传表单中常用的安全技术是在客户端验证上传的文件。一般而言，该技术在ASP.NET应用中更通用一些，因为ASP.NET提供了易用的验证控件。
这些验证控件允许开发者对要上传的文件做正则检查，以查出待上传的文件扩展名是否在允许列表中。下面是一段来自微软网站的示例代码:
<asp:FileUpload ID="FileUpload1" runat="server" />
<asp:Button ID="Button1" runat="server" OnClick="Button1_Click" Text="Upload File" />&nbsp;
<asp:Label ID="Label1" runat="server"></asp:Label>
<asp:RegularExpressionValidator id="RegularExpressionValidator1" runat="server"
ErrorMessage="Only mp3, m3u or mpeg files are allowed!"
ValidationExpression="^(([a-zA-Z]:)|({2}w+)$?)((w[w].*))
+(.mp3|.MP3|.mpeg|.MPEG|.m3u|.M3U)$" ControlToValidate="FileUpload1"></asp:RegularExpressionValidator>
<asp:RequiredFieldValidator id="RequiredFieldValidator1" runat="server"
ErrorMessage="This is a required field!"
ControlToValidate="FileUpload1"></asp:RequiredFieldValidator>
&nbsp;
这段ASP.NET代码使用了验证控件，所以最终用户只被允许上传.mp3,.mpeg,或者.m3u文件到服务器。若文件类型和这三个指定的文件类型不一致，验证控件将跑出异常，文件也就不会被上传。
由于这种文件验证是在客户端完成的，恶意用户很容易就能绕过这一检查。写一段客户端脚本来替换web应用的验证脚本做验证并非不可能。不用web浏览器，入侵者可以使用可以发送HTTP POST请求的程序来实现上传文件。
推荐的解决方案
在允许上传文件的网站和web应用中，应当应用下面的一系列最佳实践方法。这些实践方法将有助于你保证web应用的上传文件的安全性。
定义一个.htaccess文件，只允许访问指定扩展名的文件。
不要把.htaccess文件和上传文件放在同一个目录里，应该放在父目录里。
一个典型的只允许 gif, jpg, jpeg 和 png文件的.htaccess文件应当包含下面的代码(根据你的需求做调整)。这样也能阻止双扩展名攻击.
deny from all
<Files ~ "^w+.(gif|jpe?g|png)$">
order deny,allow
allow from all
</Files>
如果可能，把文件上传到root目录以外的目录里。
禁止覆盖已存在的文件（以阻止.htaccess覆盖攻击）
创建一个mime-type白名单列表。(只允许这个列表里的Mime-type)
生成一个随机的文件名，并且加上此前生成的文件扩展名、
不要只依赖客户端验证，这不够。理想的是既有客户端验证也有服务器端验证。
总结
如上所述，恶意用户有很多手段绕过文件上传表单安全验证。因此，在web应用中实现文件上传表单时，应当尊徐正确的安全指导，并且做恰当的测试。不幸的是要做足够的测试将会需要很多时间和更多的安全专家。
Fortunately With Acunetix WVS, no security expert can automatically upload forms vulnerability checks, Acunetix WVS provided with minimal time for developers can be more than enough information to track and fix the problem.