❌XSS (Cross-Site Scripting)
Last updated
Last updated
Type | Description |
---|---|
Use XSS Strike:
To fuzz: Put the burp request in xss.req
Adapt Wordlist with host ip
Testing with basic payload:
If we get alert then vulnerable. Check source code to see if it is included
To use:
Example:
We get pop-up:
Check network to add
The form would be sent in a get request so.
Here everything is done client side so no HTTP request in networks tab.
If we look at the page source by hitting [CTRL+I], we will notice that our test string is nowhere to be found. This is because the JavaScript code is updating the page when we click the Add button, which is after the page source is retrieved by our browser, hence the base page source will not show our input, and if we refresh the page, it will not be retained (i.e. Non-Persistent). We can still view the rendered page source with the Web Inspector tool by clicking [CTRL+SHIFT+C]:
The Source is the JavaScript object that takes the user input, and it can be any input parameter like a URL parameter or an input field
Sink is the function that writes the user input to a DOM Object on the page. If the Sink function does not properly sanitize the user input, it would be vulnerable to an XSS attack.
Some of the commonly used JavaScript functions to write to DOM objects are:
document.write()
DOM.innerHTML
DOM.outerHTML Furthermore, some of the jQuery library functions that write to DOM objects are:
add()
after()
append() Example code vulnerable to XSS:
To write task variable
Previous payloads won't work so
Find a working payload with XSS Then make a login form
Then use js document.write()
to write the payload.
Now to clean up:
Here the url input is still displayed. To disable. Find the id of the element and remove
Final js:
Insert this in payload.
To correctly receive the creds:
index.php:
change script.js to the field that is vulnerable
Send a request in each field like so and start the php server shown above:
Examples from PayloadsAllTheThings
Check if session cookie in storage
Cookies can be set with 2 optional flags: Secure and HttpOnly.
Secure - Only send cookie over encrypted connection like HTTPS
HttpOnly - Denies Javascript access to cookie. If not set then XSS payload can steal cookie. Check in storage section of Developer Tools If HttpOnly then we can only send through HTTP and it can't be retrieved by user thorugh Javascript then choose to create new admin users,etc.
After finding a payload that works, access the host with the payload that works
And script.js on host is one of these:
Can also use
To steal cookie: Use this in php server:
This attack works on the Visitor plugin
To attack with a HttpOnly cookie on wordpress: We need to create a Js function that fetches the nonce which is a server generated token to prevent CSRF attacks.
Now with the nonce we can create a new admin user:
Attack
First Minify the js code into a one liner in JS Compress
Then Encode the JS code with: Run it from browser console and use the encoded output
Leave intercept on in burp and run:
Forward the request and when the admin uses the visitors plugin the script will execute and create a new user.
Stored (Persistent) XSS
The most critical type of XSS, which occurs when user input is stored on the back-end database and then displayed upon retrieval (e.g., posts or comments)
Reflected (Non-Persistent) XSS
Occurs when user input is displayed on the page after being processed by the backend server, but without being stored (e.g., search result or error message)
DOM-based XSS
Another Non-Persistent XSS type that occurs when user input is directly shown in the browser and is completely processed on the client-side, without reaching the back-end server (e.g., through client-side HTTP parameters or anchor tags)