DVWA Series 16 File Inclusion Vulnerability mining and defense

DVWA Series 16 File Inclusion Vulnerability mining and defense

Next we will analyze the source code of the File Inclusion Vulnerability in DVWA.
The main page of the file is the D: \ AppServ \ www \ dvwa \ vulnerabilities \ fi \ index. php file. The main code part of the file is as follows:

In this Code, use the switch statement to separate low. php, medium. php, high. php assigns the variable $ vulnerabilityFile. Next, use the require_once function to include the page selected by the user. Finally, use the include function to include the variable $ file.
The variable $ file comes from low. php, medium. php, and high. php.
In low. php, GET the data transmitted by the user through the page parameter and assign the value to the variable $ file. We can see that the page parameter is not filtered.

In medium. in php, The str_replace () function is used to replace the data transmitted by the user, mainly to replace http: // and https: // with null, this is mainly used to prevent Remote File Inclusion.

The files we used previously contain local files on the target server. Therefore, local files include LFI and can also contain files on remote servers, such as http: // 127.0.0.1/dvwa/vulnerabilities/fi /? Page = php: // 192.168.80.132/info. php. This is called a remote file that contains RFI. Obviously, RFI is more powerful, but the premise for implementing RFI is to ensure that the two parameters allow_url_fopen and allow_url_include in PHP are enabled. These two parameters are disabled by default, therefore, most RFI cannot be executed. It is said that it can be bypassed through "zlib: //" and "ogg: //", but I have not found the relevant information yet and have not verified it, this issue should be put on hold for the moment.
In short, medium has no effect on LFI, so all previously used file inclusion operations can be performed.
Finally, let's take a look at high. php. Here, the if statement is used to determine whether the user input data is inlude. php. If not, it directly reports an error and exits, that is, it specifies that only include. PHP file. This is the most secure defense measure. Of course, in practice, you may need to select multiple files, so you only need to make several judgments. After this design, there is no File Inclusion Vulnerability.

The idea of File Inclusion Vulnerability mining is the same as before. It still searches for include (), include_once (), require (), and require_once () functions, observe whether the content of these functions can be controlled by the user and whether the defense measures are taken.
For example, in the following code, the include_once () function contains the variable $ lang, which can be input by the user without any processing, therefore, the File Inclusion Vulnerability is generated here.

Next we will analyze the source code of the File Inclusion Vulnerability in DVWA.
The main page of the file is the D: \ AppServ \ www \ dvwa \ vulnerabilities \ fi \ index. php file. The main code part of the file is as follows:

In this Code, use the switch statement to separate low. php, medium. php, high. php assigns the variable $ vulnerabilityFile. Next, use the require_once function to include the page selected by the user. Finally, use the include function to include the variable $ file.
The variable $ file comes from low. php, medium. php, and high. php.
In low. php, GET the data transmitted by the user through the page parameter and assign the value to the variable $ file. We can see that the page parameter is not filtered.

In medium. in php, The str_replace () function is used to replace the data transmitted by the user, mainly to replace http: // and https: // with null, this is mainly used to prevent Remote File Inclusion.

The files we used previously contain local files on the target server. Therefore, local files include LFI and can also contain files on remote servers, such as http: // 127.0.0.1/dvwa/vulnerabilities/fi /? Page = php: // 192.168.80.132/info. php. This is called a remote file that contains RFI. Obviously, RFI is more powerful, but the premise for implementing RFI is to ensure that the two parameters allow_url_fopen and allow_url_include in PHP are enabled. These two parameters are disabled by default, therefore, most RFI cannot be executed. It is said that it can be bypassed through "zlib: //" and "ogg: //", but I have not found the relevant information yet and have not verified it, this issue should be put on hold for the moment.
In short, medium has no effect on LFI, so all previously used file inclusion operations can be performed.
Finally, let's take a look at high. php. Here, the if statement is used to determine whether the user input data is inlude. php. If not, it directly reports an error and exits, that is, it specifies that only include. PHP file. This is the most secure defense measure. Of course, in practice, you may need to select multiple files, so you only need to make several judgments. After this design, there is no File Inclusion Vulnerability.

The idea of File Inclusion Vulnerability mining is the same as before. It still searches for include (), include_once (), require (), and require_once () functions, observe whether the content of these functions can be controlled by the user and whether the defense measures are taken.
For example, in the following code, the include_once () function contains the variable $ lang, which can be input by the user without any processing, therefore, the File Inclusion Vulnerability is generated here.