If you're a frontend developer coding a modern web application you're probably using ReactJS or one of the other javascript frameworks. When analyzing ReactJS and other frameworks you typically break it up into two steps, first you do some recon by analyzing the source code then look for dangerous functions and sensitive information. I've found XSS a bunch of times using this workflow, I use the same trick each time.
With ReactJs you can make use of “sourcemaps” to get the raw source code. I'm not talking about the compiled javascript, I'm talking about the raw source code for the entire project. After that you can “grep” for dangerous functions. React by default mitigates a lot of XSS possibilities but there are still interesting ways developers can mess up.
ReactJS and other javascript frameworks like Vui and Angular function a little differently than your traditional PHP sites. They use javascript for everything and it's all dynamically generated at runtime so looking at the raw HTTP response to view the source code doesn't work. You will see something like this:
If you ever see that your probably dealing with a frontend built with a javascript framework. Pay close attention to the words “You need to enable JavaScript to run this app”. Also notice there is a javascript file called /static/js/main.<random>.js . That javascript file can be used to view the raw reactJs code. To view the raw source code you can use chrome tools then go to sources as shown in the image below:
There are a couple signs that you're dealing with the raw reactJS code. First look at the folder node_modules if you see that you're probably dealing with ReactJS, it's used to hold all of the third party libraries you install. Also look at the “js” file and its structure, it's very common for developers coding in reactJS and other frontend languages to use a folder structure like this. If you see a “components” folder or a “pages” folder then it's probably ReactJs.
While analyzing the source code there are a lot of things we can look for. I have a lot of tips and tricks here, but I'll have to do a blog on that later as this post is on finding XSS. By default react prevents most XSS scenarios but developers often find ways to sneak them in. The easiest way to spot a potential mess up is to grep for dangerous functions.
Its pretty easy to find just search for “dangerouslySetInnerHTML” . The dangerouslySetInnerHTML function in react is a special prop used to inject raw HTML directly into the DOM from a React component. It bypasses React's built-in DOM escaping mechanism, which normally protects against cross-site scripting (XSS) attacks. So if a developer is using this function they are using it to inject HTML into the DOM, if they pass user input then you can leverage it to get XSS.
You could report the use of the dangerouslySetInnerHTML as a bug or you could try to leverage it to get XSS. You will need to analyze the source code a little further to see how to exploit it. Just because a developer uses this function doesn't mean you can exploit it. You need to find out if the function is using any user input that you control. For example it might be taking text from a search field and concatenating that with results , taking information from an API where you control the data, and other more. If you control the data to this function then you can get XSS, if you dont then you can’t.
At this point Ill throw it in ChatGPT and have it analyze the source code for me. You have access to the raw source code so just copy paste it into an LLM and give it a prompt like this:
Please analyze the following ReactJS code to determine whether the use of dangerouslySetInnerHTML introduces a cross-site scripting (XSS) vulnerability. Examine how the input passed to dangerouslySetInnerHTML is generated or retrieved. Specifically, I want to know if the input comes from user defined or untrusted sources. If the content passed into dangerouslySetInnerHTML is influenced by user input, describe how an attacker could potentially inject malicious HTML or JavaScript into the application. Provide a clear explanation of the conditions required for this vulnerability to be exploitable. If there is no XSS risk, explain why the usage of dangerouslySetInnerHTML is considered safe in this case. Mention any sanitization steps or controlled data flows that prevent injection. Your analysis should include a summary of the code’s behavior, potential attack vectors, and a conclusion on whether the function can lead to XSS in this specific implementation.
As you can see, if I can control the output of that API call then I can get XSS. In this specific application it turned out that I could indeed control the output of that API call allowing me to get a stored XSS vulnerability.
My company stealthnet.ai is building a fleet of AI Agents to help automate penetration testing. Our external agent can automatically find vulnerabilities like this at scale. For example all you have to do is put in a domain and it will automically find and scan all subdomains, detemrin if they are running react, if they are it will check for this vulnerbility. It will also write the report for you as shown in the image below:
If you are testing a ReactJS application, always look for sourcemaps so you can analyze the raw source code. Once you have the source code just search for dangerous functions such as “dangerouslySetInnerHTML”. Finally , analyze the source code with AI and have it tell you how to leverage the use of this function to get XSS. When I'm looking at a site this entire process typically takes me a few minutes, it's super easy to do and often leads to wins.