I am trying to pentest a webapp challenge. Is the following control code vulnerable to file upload? I would like to upload a php shell...

I am able to upload shell.php.jpg file but I receive the error when I load the file location.

function limitText(limitField, limitNum) {
    if (limitField.value.length > limitNum) {
        limitField.value = limitField.value.substring(0, limitNum);

var input_file = document.getElementById('image_file');
input_file.onchange = function() {
    var extension = $('#image_file').val().split('.').pop();
    switch (extension.toLowerCase()){
        case 'png':
        case 'jpg':
        case 'jpeg':
            alert('Invalid file name');

  • 3
    Is there just client-side validation? What happens if you simply disable JavaScript?
    – Gumbo
    Commented Mar 7, 2014 at 23:26

1 Answer 1


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 “file.PHp3”).
  • 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: “file.asp;.jpg”).
  • 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 directory).
  • 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: “file.asp::$data.”.
  • 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 attacks.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .