Find XSS candidates reflected in the source code
Use Ocular to find the XSS reflected in an app
When learning to find, exploit, or prevent security vulnerabilities, it’s important to understand the root causes of the vulnerability and what actually makes an application vulnerable.
Today, let’s talk about an extremely common vulnerability, XSS, its mechanisms and how you can spot it in the source code.
How XSS Happens
Cross-Site Scripting, or XSS, vulnerabilities occur whenever an attacker can run malicious scripts on a victim’s browser.
Applications often use user input to create web pages. For example, a site might have a search feature where the user can enter a search term, and the search results page will include the term at the top of the results page. If a user searches for abc, the source code for that page might look like this:
You searched for abc; here are the results!
But what if this app can’t tell the difference between user input and the legitimate code that makes up the original web page?
Attackers might be able to submit executable scripts and embed this script on the victim’s web page. These malicious scripts can be used to steal cookies, disclose personal information, modify site content, or redirect the user to a malicious site.
For example, if the app also allows users to search via URLs:
If an attacker can trick victims to visit this URL:
The URL script will be embedded in the page visited by the victim, which will force the victim’s browser to execute the code desired by the attacker. This is called a “XSS reflected”Attack.
Data flow analysis
Before you research the XSS reflected in an application, you should understand a few code review concepts: “sources”, “sinks”, and “data streams”. In code analysis, a “source” is the code that allows a vulnerability to occur. Whereas a “sink” is where the vulnerability actually occurs.
Take command injection vulnerabilities, for example. A “source” in this case could be a function that takes user input into account. While the “sink” would be functions that perform system commands. If untrusted user input can move from “source” to “sink” without proper cleanup and validation, a command injection vulnerability exists.
Many common vulnerabilities can be identified by following this “data flow” from the appropriate sources to the appropriate sinks.
The vulnerability we’ll be looking at today is XSS.
What are the sources and sinks of XSS? With all XSS vulnerabilities, we are basically looking for user input used in the server output which will be displayed to the user.
Let’s start looking for XSS candidates reflected in a sample app! We will launch the analysis tool that we are using today, named Ocular, and import the project that we are analyzing. We are analyzing a vulnerable Java application called Tarpit Java.
After importing the project, I like to run a command to make sure the project loads properly. I usually run cpg.method.name.l for this purpose. This command will search for all the methods defined in the project, extract their names and list them.
Our code was imported correctly! Let’s start looking for a thoughtful XSS by looking for the sources of an XSS vulnerability. Typical sources of an XSS vulnerability are where the application takes user input into account. A good way to identify these locations is to look for identifiers (local, global, and class members) that are of type HttpServletRequest. We will therefore filter the list of identifiers by its type name. With Ocular, you can search for channels with regex:
Here we are basically looking for ids whose type name contains the string HttpServletRequest. This gives us a list of IDs that contain entries from HTTP requests.
We will define this as our source.
Next, find the receiver functions for XSS. This is usually any place where the application displays output for a user, such as HTTP responses, prints to log files, etc. To keep things simple, we can find all calls to print functions in the app. Specifically, we are looking for data passed as arguments to print functions:
Finally, we can tell Ocular to show all the places where a source can reach a sink in terms of data flow, and display the results nicely:
Let’s take a look at one of these data streams to check for potential XSS! What the data feed is telling us here is that the request id on line 83 of insider.java will end up being printed on line 87 of insider.java as a parameter named x:
When we go into the source code of Tarpit Java, you can see that the code does lead to XSS.
Static analysis is the most efficient way to discover most vulnerabilities in your applications. If you want to learn more about the static analysis tools of ShiftLeft, ShiftLeft CORE or Ocular, visit us here. And if you want to learn more about common web application vulnerabilities, check out our free course on the top ten OWASP.
By the way, you can watch the video version of this demo here:
Finding XSS Candidates Reflected in Source Code was originally posted on ShiftLeft Blog on Medium, where people continue the conversation by highlighting and responding to this story.
*** This is a Syndicated Security Bloggers Network blog from ShiftLeft Blog – Medium written by Vickie Li. Read the original post at: https://blog.shiftleft.io/find-reflected-xss-candidates-in-source-code -c6fcedc82cb0? source = rss —- 86a4f941c7da — 4