It looks like you're only looking at the file extension. This is not effective. For a description of why, and a list of viable protections, please refer to the OWASP article on "Unrestricted File Upload".
Excerpt: (Some of this may not be directly applicable to your environment, but I'm not editing those out.)
Using Black-List for Files’ Extensions
Some web applications still use only a black-list of extensions to
prevent from uploading a malicious file.
- It is possible to bypass this protection by using some extensions which are executable on the server but are not mentioned in the list.
(Example: “file.php5”, “file.shtml”, “file.asa”, or “file.cer”)
- Sometimes it is possible to bypass this protection by changing some letters of extension to the capital form (example: “file.aSp” or
- Using trailing spaces and/or dots at the end of the filename can sometimes cause bypassing the protection. These spaces and/or dots at
the end of the filename will be removed when the file wants to be
saved on the hard disk automatically. The filename can be sent to the
server by using a local proxy or using a simple script (example:
“file.asp ... ... . . .. ..”, “file.asp ”, or “file.asp.”).
- A web-server may use the first extension after the first dot (“.”) in the file name or use a specific priority algorithm to detect the
file extension. Therefore, protection can be bypassed by uploading a
file with two extensions after the dot character. The first one is
forbidden, and the second one is permitted (example: “file.php.jpg”).
- In case of using IIS6 (or prior versions), it might be possible to bypass this protection by adding a semi-colon after the forbidden
extension and before the permitted extension (example:
- In case of using IIS6 (or prior versions), it might be possible to bypass this protection by putting an executive file such as ASP with
another extension in a folder which ends with an executive extension
such as “.asp” (example: “folder.asp\file.txt”). Besides, it is
possible to create a directory just by using a file uploader and ADS
(Alternate Data Stream). In this method, filename should end with
“::$Index_Allocation” or “:$I30:$Index_Allocation” to create a
directory instead of a file (example:
“newfolder.asp::$Index_Allocation” creates “newfolder.asp” as a new
- This protection can be completely bypassed by using the e.g. control characters like Null (0x00) after the forbidden extension and
before the permitted one. In this method, during the saving process
all the strings after the Null character will be discarded. Putting a
Null character in the filename can be simply done by using a local
proxy or by using a script (example: “file.asp%00.jpg”). Besides, it
would be perfect if the Null character is inserted directly by using
the Hex view option of a local proxy such as Burpsuite or Webscarab in
the right place (without using %).
- It is also possible to create a file with a forbidden extension by using NTFS alternate data stream (ADS). In this case, a “:” sign will
be inserted after the forbidden extension and before the permitted
one. As a result, an empty file with the forbidden extension will be
created on the server (example: “file.asp:.jpg”). Attacker can try to
edit this file later to execute his/her malicious codes. However, an
empty file is not always good for an attacker. So, there is an
invented method by the author of this paper in which an attacker can
upload a non-empty shell file by using the ADS. In this method, a
forbidden file can be uploaded by using this pattern:
- In Windows Servers, it is possible to replace the files by using their short-name (8.3). (example: “web.config” can be replaced by
uploading “web~1.con”) Sometimes combination of the above can lead to
bypassing the protections.
Using White-List for Files’ Extensions
Many web applications use a white-list to accept the files’
extensions. Although using white-list is one of the recommendations,
it is not enough on its own. Without having input validation, there is
still a chance for an attacker to bypass the protections.
- the 3rd, 4th, 5th, and 6th methods of last section apply here as well.
- The list of permitted extensions should be reviewed as it can contain malicious extension as well. For instance, in case of having
“.shtml” in the list, the application can be vulnerable to SSI