Website Hacking, Part III

Introduction

In this part of the Website Hacking 101 series, we are going to discuss controlling access to directories (if access is not controlled by key directories like include/includes, the system can be accessed simply by guessing the URL), direct static injection (A Direct Static Code Injection attack consists of injecting code directly onto the resource used by application while processing a user request), file inclusion vulnerability (especially when dealing with files from external servers) and database security (quick guide).

Exercise 9: Controlling Access

It is always good practice to control access to your assets. There are directories and files that you do not want to be accessed by ordinary users.

For instance, most apps have a system or include/includes directory.

If the script in the includes directory is not written well enough to handle access outside the usual include statement, it might trigger some errors which would reveal information to possible attackers. For example, errors can reveal your hosting account which could lead to brute-force/dictionary attacks on your hosting account (that is just one simple example). Also, if a user opens a file with an extension .inc instead of .php – the code will not execute and will be printed as is. All files that do not contain server-side code or are not named properly will also be readily available for examination.

Figure 1: Unprotected includes directory. All assets are revealed.

The attacker can then test all the different assets for errors and start gathering information about additional vulnerabilities.

Figure 2: Some of the includes do trigger errors

As we mentioned before, a possible solution is to set display_errors to Off in the php.ini file or to use ini_set (‘display_errors’, ‘off’) in the code of a particular script.

However, it is a better alternative to deny access to everyone but the server to this directory. In that way, your pages which include or require files from that directory can still access them but requests from a visitor (the client) would trigger an error.

You simply create an .htaccess file in the forbidden-to-be directory and insert:

where 127.0.0.1 can be used for localhost. You can also insert directly a domain name or your server’s IP address. There are myriad websites that show the IP address of the server, should you be in doubt about it.

IMPORTANT: If you enable access to directories/files only from the server, you will be able to access them with functions such as include, require, fopen and file_get_contents, but users would not be able to access the files if the link was provided as an href attribute to an <a> tag or if the request for the file is made via an ajax call, since such requests also come from the client and not from the server itself. Thus, use this method only for directories/files that are not normally requested by the client.

Alternatively, you can deny offending parties (such as spammers) access to your app by getting the $_SERVER[‘REMOTE_ADDR’], $_SERVER[‘HTTP_X_FORWARDED_FOR’] or $_SERVER[‘HTTP_CLIENT_IP’] (one of the last 2 values may be set if the client is using a proxy) array elements and writing the offending IP to the .htaccess file along with a ‘deny from’ directive.

Exercise 10: Direct Static Injection (Your visits)

Let’s say that we have an app that logs data about each visit of its users. The data can include the user’s IP, browser & OS and date and time of the visit. This data can then be shown to the user so he can check for illegal logins or it can be processed by some script to check for abnormal user behavior.

Such an app can be vulnerable to direct static injection, because the gathered data can be tampered with by the user to include code which will execute itself when the user visits his log.

Figure 3: How a user log may look. In this sample, the user clicks on the button, types his name and sees all data about that name. There is no session/cookie/authentication.

From the data in the log, we can determine that $_SERVER[“HTTP_USER_AGENT”] is used to gather information about the user’s browser & OS.

Thus, we can easily start Tamper Data and change the User-Agent to include a piece of code that we want to try to execute and if the data is not properly sanitized – it will work.

Figure 4: Changing the User-Agent Header

The first time I changed it to <?php echo “I EXECUTED PHP SCRIPT “” ?> and I saw that it worked, so now I know that I can execute arbitrary code in the webpage. For example, here is what I get if I change the user-agent to <?php phpinfo(); ?>

You can basically ruin this website. That is why our next exercises will touch on input sanitation.

Exercise 11: File inclusion vulnerability

There are times when you are required to load files from external servers. Sometimes the PHP code inside these pages has to be executed as well. If you want to use include() or require() you would need to set allow_url_include to ‘on’ in the php.ini file. It is not possible to turn it on using ini_set(‘allow_url_include’, ‘on’) inside the script. However, you can always create your own custom php.ini file and enable them there should you be using shared hosting (See Appendix 1 to see how to create custom php.ini in shared hosting). Furthermore, to turn on allow_url_include, allow_url_fopen has to be turned on. If the file that you want to get is not expected to contain php code, you can use file_get_contents to get its contents. If you want to use that function and still execute php code, you should evaluate the contents after loading them – eval().

In the example website, we have used the following method to load any file.

If your website requires, it is a good idea to rely on whitelisting to filter out bad files.

If we did not employ the whitelisting, the following and many more things could happen:

Figure 5: The attacker can get the user’s cookies

The attacker can give a URL to the website’s URL on which his own external script is loaded to a third user that uses the website to get the user’s cookies. He can even save them on a .txt file in the server which he can easily access to check for newly gathered cookies.