Vulnerable applications: exploring the DVWA #3

3 minute read

The next vulnerability that we will be looking at will be File Inclusion.

What is it?

Many website frameworks try to be generic and allow their users to include pages they have made themselves. This is done by including the page (the actual PHP script in this case) into the template page, rendering the content from that included page as if it were part of the template page.

This sounds very convenient, but what if you could trick the system into loading any page you would like? In this post we will find out how this works.

File Inclusion

Low security

The lowest security setting should be no trouble for us. When you click on one of the files we see that the browser actually passes the filename to the page parameter: http://localhost:32770/vulnerabilities/fi/?page=file1.php and then loads the file into the page.

File Included

Lets try to load up a well known file such as /etc/passwd. On a Linux operating system this file contains the list of users on the system, in case you didn’t know. The URL will be http://localhost:32770/vulnerabilities/fi/?page=/etc/passwd.


Sure enough, the contents of the file is added to the top of the page as we would expect. If it is really badly implemented you could even include files from other websites, lets try my blog http://localhost:32770/vulnerabilities/fi/?page=

My Blog Included

Wow, it just worked! This means that low security really means no security at all. Lets level up!

Medium security

Sadly we are no longer able to include my wonderful blog as a source. But what about a direct file inclusion? Lets try to include something from the application itself.

We will need to know some things about the application; in what directory is it running and what files are available? In the previous post we examined command injections, lets use them to find these things out.

|| pwd tells us we are in the directory /app/vulnerabilities/exec. If we look at the current url for file inclusion we see the following URI: /vulnerabilities/fi. This means that the document root is at /app. By browsing around using || ls ../.. we find several interesting files in the /app directory. Lets try to include the to see if it all works. If we use relative paths (../../ this does not work, but direct (/app/ works like a charm!


On the low level relative paths worked, so on medium security both URLs and relative paths are filtered.

High security

Well this is a bummer, everything we previously used stopped working. For every request we are now greeted with a big fat ERROR.


We know, from the screen itself, that there are 3 files to include, lets try to increment the counter of the file. Perhaps there are other files we can take a look at?


Hey, thats nice, we found a hidden file! If we were playing capture the flag it would probably have a nice flag to score some points!

At file5.php the screen turns blank. No error, nothing. That is odd, because the other files we tried to include returned an *ERROR. Lets try to fuzz the filename to see what will cause an error or a blank screen. Changing the number or increasing the filename to things like filename.php or file1more.php all yield a blank page. Lets start removing characters from the filename to see what triggers this change.

file1.php, normal page., blank page. file, blank page. fil, error! Ok, so it seems there is something special going on with file and anything larger!

This reminds me of the File URI Scheme which is basically the same as an URL, but then to access files. both http:// and file:// are protocols that can be used to access information.

If we enter file:// as the page again we are returned a blank page again, lets try file:///etc/passwd to access the local password file.

File Protocol

Yes! The file is loading again as it did before!

impossible security

I tried everything I know, but couldn’t figure it out. Looking at the source they whitelisted only the specific files that are to be loaded, so there seems to be no way to actually load anything else…