DEXTUploadJ
Security Development Guide

Security Development Guide

A service that provides the file upload function can be attacked that may affect the security from the outside.

For instance, the attacker can execute the Web-shell on the server by uploading the malicious file.

Most of the service includes the file attachment function. But if the security code verifying the validity for the upload file does not exist, attackers can gain the authority of the server by abusing this situation or try harmful acts on the service.

Basically, All platforms such as ASP, ASP.NET, PHP, JSP(Servlet) do not have a defense of verifying for uploaded file. Therefore, The developer who provides the service should create the working code to verify the file data which is sent from the clients(browser, third-party).

Filtering the file extension in the client

You should do filtering to select only files that allowed to upload in the file attachment function.

The file type of attachment depends on the service feature, but in the general case, you should not allow to upload the file except commonly used media file. (Permit the doc, docx, xls, xlsx, hwp, …, jpg, png etc.)

Therefore, such as jsp, asp, php, cgi files, except the media file are prohibited uploading.

In case of using the pure HTML, you can inspect the file extension by using the javascript code and in case of using the component by using the Plug-in like the ActiveX, you should use component’s own extension filtering function.

The code that validate the file extension should use the White List(A way to check the file extension whether it is able to upload) rather than the Black List(A way to check the prohibited uploading file extension).

The data modulation can occur in the process of being sent to the server, even if you went through proper verification in the client side.

At the HTTP protocol, there is no way to protect it, so you should work encrypted transmission by using the SSL(Secure Socket Layer.)

As a developer side, there is no part of processing because the SSL encryption at the Transport Layer.

But the applied service can be diminished in performance because the SSL has the encryption or decryption process.

Filtering the file extension in the service

Even if filtering the file extension was verified from client side, you should do same test on the server code because it is able to make a detour easily.

Just like the client test way, The extension test should be performed by White List base. And it is recommended to check intactly the filename delivered from the client side without preprocessing.

For instance, you should test the original filename intactly to the exclusion of doing the trim or working to remove all special letters. At first, if the file has the extension which is not included in the White List, you should not save this in the server.

In case of filtering the extension with the Black List method, you should use the verification method of the White List because the attacker can find the pattern which is not included in Black List and attack.

Removing the execution authority of the upload directory

As long as there is no particular purpose, the normally uploaded file becomes an object of downloading.

Even if the Web-shell file is saved, If this file does not run, it will not affect at the security seriously.

Therefore, the directory which saves the file should be removed the execution authority.

 

Example) IIS6 security setting

After selecting the object directory at the IIS setting, open the properties window and set up the execution authority as the 'n/a'.

 

Example) in case of the higher than IIS7

In case of the higher than IIS7, after selecting the upload directory, open the 'Handler Mappings' tool and change the authority.

In the 'Edit Feature Permissions' window, uncheck the 'execute' and 'script' items.

 

Example) in case of the Apache

In case of the Apache, you can use the method to limit the object of the file rather than to remove the authority.

#httpd.conf
<Directory directory-path>
	AllowOverride FileInfo (or 'All' available)
</Directory>
							

Create the .htaccess file under the upload directory and change the particular MIME-TYPE to make Web-shell not be run.

<FilesMatch "\.(php|pl|cgi|inc|lib)">
Order allow, deny
Deny from all
</FilesMatch>
AddType text/html .html .htm .php .php3 .php4. phtml .phps .in .cgi .pi .shtml .jsp
							

 

Please refer to the Apache .htaccess file setting for details.

http://httpd.apache.org/docs/2.4/mod/core.html#allowoverride

http://httpd.apache.org/docs/2.4/howto/htaccess.html

 

For the setting of other Web server or WAS server, refer to the related document.

Removing the external exposure of upload directory route

There are many cases that developers expose the location of the file upload directory to the web address normally for developer’s convenience.

Normally developers develop the uploading process carefully. However there are many cases that developers entrust the download section to the web server without the additional processing, so it will be target to run uploaded Web-shell.

Therefore, the file upload directory route primarily should be avoided the setting it to the sub-directory route. And even if you use the external directory, you should not enroll in the web-imaginary-directory to guard against the access of web address.

Instead, for downloading, you should develop the download module. And in this module, you should develop the function to read a file and transfer it from the external directory.

Changing a policy of file management architecture

There are many cases that develper decides a policy to save the filename intactly.

But in this case, it will be primary condition to attack the Web-shell as well as writing the additional code to avoid the duplicate filename.

The file for upload should be made and saved with a special filename to match the service policy without using the original filename.

 

Example)

F[upload date -> yyyyMMddHHmmssfff]_[remote ip]_[session/ID]_[thread]_[turn].[insignificant extension]

attack.jsp -> F20130401153027125_111.111.111.111_0012345_100_0001.bin

 

And the actual local filename should be enrolled in the database for the download service.

At this moment, if you enroll the the size, extension and MIME-TYPE(if possible) together, it offer help your security and service implementation additionally.

And if you implement(realize) the download that can download by using the download module, you can download the user-friendly filename which is enrolled in the database.

The attackers can't attempt the attack because they can't know the file name to perform the Web-shell. And it can block the Web-shell's attack basically, because the attacker can access the files through only the download module, and the server does not run the file and unconditionally transfers the file to the client.

DEXTUploadJ

DEXTUploadJ has not its own security function to defend file upload attack.

 

DEXTUploadJ can save the original filename intactly, add the turn on the filename or use the save as task.

But regardless of the product, if the filename is included with the special letter or nonpermissive letter, it can be saved with unintended filename or the error can be occurred.

Therefore, Before saving the file, check the filename is valid.

 

[The method that can be used to enhance the security and the recommendation]

  • Before saving the file, you can find out the filename to be saved by using the getFileName method of FileItem class.
  • The getMimeType of FileItem class returns the MIME-TYPE of the file. But MIME-TYPE can be modulated or be processed with like the application/octet-stream, application/unknown format without the file division on the client side.
  • Basically DEXTUploadJ includes the FileDownload class to download the file.