This section talks about the prevention of vulnerabilities. A lot of vulnerabilities exist because of the functionalities that they provide.
For example, in the first section, File upload vulnerabilities, we talked about allowing the upload of any file extension. The ideal case is to check the file type, if a user is uploading a file; it should be an MP3 or a media file, not a PHP file or some executable code. We should never allow users to upload executables. Filters can be used to check the extension. The best way to do this is to check the file instead of just checking the extension, because files can bypass the extension check. Check the picture or the media instead of relying on the extension.
In the second section, Code execution vulnerabilities, we explored how we can run any code on a target computer. We should avoid allowing users to run code on the server. Also, avoid functions such as eval and passthru, which allow users to run OS code on the server. If we have to use these functions, analyze the input before execution.
Take a look at this, for example:
10.0.2.15; ls-la
Suppose we type an IP, 10.0.2.15, and then add a semicolon, and a command, ls-la. The only problem is the web application accepts the information the way it is copied and run. When we execute the command, we will see the IP address first and then the ls-la command. In such cases, check the input that was entered. If we are expecting an IP address, we can use a regex. A regex is a rule that will ensure that the input conforms with the format 10.0.2.15. If we enter any other input, the web application would reject it. We should also ensure that there are no semicolons or spaces, and that everything comes as one thing and gets executed. These are many secure ways of execution, but the best thing to do is avoid eval and passthru functions.
The third section was on file inclusion, which was further divided into local and remote file inclusion. Local file inclusion allowed us to include any file on the target system, and to read files that had been disclosed by a vulnerability. Remote file inclusion was also looked at, which allows us to include any file from a web server that has PHP shells and gain a connection to the target computer.
We need to prevent remote file inclusion so that people cannot include files outside our server. We can enable this method using the php.ini file by disabling the allow_url_fopen and allow_url_include functions. To disable the functions, follow the steps used in the Remote file inclusion using Metasploitable section.
Ensure that the settings for allow_url_fopen and allow_url_include are set to Off:
The other way to prevent these exploits is to use static file inclusion. So instead of using dynamic file inclusion, which we've seen, we can hardcode the files that we want to include in the code and not have to get them using GET or POST.
For example, in the vulnerability cases, we used the page parameter with the index.php page. Now, the index.php page uses the include parameter or otherwise takes another page called news.php, which will be included in the $_GET(); parameter in the code. The following screenshot explains the vulnerability:
The fundamental thing is to include files that come after the page parameter. The code will dynamically take the files that come after the page parameter in the URL and include everything from URL to the current page. In some cases, we tend to use the POST method, which will not get the same executions; however, in such cases, it's best to use a proxy, such as Burp Proxy. It will help us to make modifications and include the files that we want to display. By using this approach, we won't be able to manipulate anything inside the page that is included. To avoid hard code and prevent using a variable, simply provide the page that needs to be included. This will make the code look longer but the page will be much more secure.
The following screenshot shows us an easier way of hardcoding:
