Vulnerabilità del caricamento di file

Question

Vulnerabilità del caricamento di file

#1 da (2 voti)

1

Sto provando a pentestare una sfida webapp. Il seguente codice di controllo è vulnerabile al caricamento di file? Vorrei caricare una shell PHP ...

Sono in grado di caricare il file shell.php.jpg ma ricevo l'errore quando carico il percorso del file.

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':
            break;
        default:
            alert('Invalid file name');
            $('#image_file').val("")
    }

    return;
};

javascript web-application penetration-test file-upload

posta purcel 07.03.2014 - 22:02

fonte

1 risposta

Leggi altre domande sui tag javascript web-application penetration-test file-upload

Scelta di un algoritmo di crittografia per token di autenticazione passati tramite AJAX Cronologia delle password con PBKDF2

score 2 · Answer 1

Sembra che stai guardando solo l'estensione del file. Questo non è efficace. Per una descrizione del perché e un elenco di protezioni valide, fai riferimento a l'articolo OWASP su "Caricamento file illimitato" .

Estratto: (Alcuni potrebbero non essere direttamente applicabili al tuo ambiente, ma non li sto modificando.)

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.