I am learning about file upload vulnerabilities using DVWA.

After cranking the website's security level to High, the website checks both the post request's content type & file extension, so in order to bypass it I changed the file extension to .jpg and used Burp Proxy to change the file name to shell.php.jpg from shell.jpg in order to execute the shell.

changing filename with burp

It works. What I don't understand is why it works. I read that only the right most file extension pattern is treated as the file extension, So that must mean shell.php.jpg should be treated as a .jpg file, and It is treated as such - the upload succeeds.

But why can I execute this file and not a shell.jpg file if the file extension stayed the same and the .php part is just part of the file name?

root@kali:~# weevely yuval

[+] weevely 3.7.0

[+] Target: www-data@
[+] Session:    /root/.weevely/sessions/
[+] Shell:  System shell

[+] Browse the filesystem or execute commands starts the connection
[+] to the target. Type :help for more information.

weevely> id
[-][channel] The remote script execution triggers an error 500, check script and payload integrity
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@ $ 

Example of the file working as expected named as shell.php.jpg.

root@kali:~# weevely yuval

[+] weevely 3.7.0

[+] Target:
[+] Session:    /root/.weevely/sessions/

[+] Browse the filesystem or execute commands starts the connection
[+] to the target. Type :help for more information.

weevely> id
[!][terminal] Backdoor communication failed, check URL availability and password

Example of the same file NOT working as expected named as shell.jpg.

  • It shouldnt work.How is it working for you – yeah_well Jul 17 '19 at 17:43
  • The help section states to use another vulnerability along with it to get the shell – yeah_well Jul 17 '19 at 17:43
  • @VipulNair Mind linking me to this help section? – LazyDaisy Jul 18 '19 at 8:33
  • cd /var/www/html/DVWA-master/vulnerabilities/upload/help/ – yeah_well Jul 19 '19 at 14:00

shell.php.jpg should be treated as a .jpg file

You're exploring DVWA, so not every should be means is. If I had to guess, the upload script properly checks the extension of the file and allows it, but the webserver doesn't check it the same way and allows execution.

You can learn more by exploring web server's (nginx or apache) config files, look for a block that performs handover to php parser for request processing.


But why can I execute this file and not a shell.jpg file if the file extension stayed the same and the .php part is just part of the file name?

The extension is just letters in a file name, they do not determine how the file is handled by the web server, web server determines it. One of the common algorithms is:

If the requested file name ends with “php”
    Invoke php to handle the request
    Serve the requested file like any other static file

I’m guessing that in your case requested file name ends with “php” is changed to requested file name contains “.php”. You can find this rule in the configuration file of the web server that’s processing your requests and find out for yourself.


This is the expected and documented behaviour of apache. I'm a little bit surprised, but this is the world we live in. Goddamnit.

In configuration file /etc/apache2/mods-enabled/php.conf line AddHandler php5-cgi .php registers handler for .php files. Everything is OK, unless you read what AddHandler does.

The extension argument is case-insensitive and can be specified with or without a leading dot. Filenames may have multiple extensions and the extension argument will be compared against each of them.

Sooo... Yeah. Of course filenames may have multiple extensions. This is the only logical default.

If you're a weirdo expecting that the file would have only one extension, apache has the answer for you:

If you would prefer only the last dot-separated part of the filename to be mapped to a particular piece of meta-data, then do not use the Add* directives.

They helpfully suggest the solution to your weird wish of one-extention-ness – just use regex. So in order to execute only .php files as php you need to replace AddHandler directive in php.conf with

<FilesMatch "[^.]+\.php$">
  SetHandler php5-cgi

In conclusion:

  • common sense doesn't exist in software
  • never trust any data provided by user
  • store original filenames in the database if needed and rename them after upload
  • treat filenames like a live bomb
  • Sorry for my ignorance but I still can't understand how this answers my question, mind elaborating? – LazyDaisy Jul 18 '19 at 8:34
  • @Yuval tried to clarify it a bit. In the end your question is about web server’s behavior, and the answer is in the config files of the server. – Andrew Morozko Jul 18 '19 at 12:27
  • Not knowing anything about DVWA I expect this to be the correct answer. Now I think about it, I've seen this vulnerability in my nodejs express configuration. However, concerning DVWA, it seems to be a straw-man when it comes to vulnerability. Does DVWA have documentation on why this works? – Nathan Goings Jul 18 '19 at 13:59
  • Thanks for clearing it! I didn't even think that the server would handle the requested file in such a way, sounds a bit basic to check if it ends with and not if it contains... I want to hope its part of what makes DVWA so damn vulnerable? lol @NathanGoings I could not find any documentation for DVWA, do you recommend a better - more documented vulnerable website? (: – LazyDaisy Jul 18 '19 at 18:49
  • @Yuval, My website circa 2004 was way more vulnerable. I'm not really suggesting an alternative to DVWA, you did learn about contains-vs-ends-with, so I think it's solving it's purpose. Here's the documentation I found: github.com/ethicalhack3r/DVWA/blob/master/docs/DVWA_v1.3.pdf – Nathan Goings Jul 18 '19 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.