Were you ever curious to know what are the most frequently found vulnerabilities in the Zerocopter platform? After collecting internal statistics on a 12 months period, we have determined the top 5 vulnerabilities for Bug Bounty programs and Coordinated Vulnerability Disclosure programs!
In this blog series, our Security Analyst, Lennaert Oudshoorn, together with our Triage Officer, Laura Laan, are getting into details about each and every vulnerability and explaining the core of those, their impact and ways of prevention.
Our first blog is about the Cross-site scripting (XSS) vulnerability. We chose to discuss about this vulnerability first because 13,4% of all Bug Bounty reports were XSS, making it the most found vulnerability in the Bug Bounty programs! But how many types of XSS are out there? What is their impact, as well as tips to mitigate the consequences, are some of the things that we will discuss in this blog.
What is XSS?
Cross-site scripting or XSS is a vulnerability typically found in web applications. It’s a type of injection which allows an attacker to execute malicious scripts on a victim’s machine. When no security measures are taken the browser has no way of knowing that the script should not be trusted. This way the attacker can gain access to any sensitive information the browser has access to.
There are different types of XSS and each has different impact. Let’s take them one by one:
Stored XSS
Stored XSS, also known as persistent XSS, is a type of XSS where the malicious script is saved on the targeted server. After saving the script on a server all the attacker has to do is wait for victims to view the webpage containing the malicious script on this server. Once a victim views this page the malicious script is executed in their browser.
Stored XSS is a dangerous type of XSS as many victims can be attacked with a single payload. The victims don’t have to take any extra steps besides accessing a normally trusted website.
Reflected XSS
Reflected XSS is when the malicious payload is part of the request to a website. The victim needs to click on a link for this attack to be successful. An attacker can try to trick a victim into clicking on a link by email or another type of message. After the victim views this website through the malicious link the website includes this payload in response back to the victim.
DOM based XSS
A DOM-based XSS vulnerability exists when JavaScript takes data from an attacker and passes it on to a sink. The Document Object Model, or DOM, is an interface through which JavaScript can interact with the HTML of a webpage. A sink is a JavaScript function or a DOM object that can execute a malicious script during a XSS attack. DOM based XSS is like reflected XSS generally achieved by tricking a victim into clicking on a link.
The difference between these types of attacks is that with reflected XSS the payload is placed in the response page and with DOM based XSS this happens in the client side code contained in the page.
Self XSS
During a self XSS attack the victim is tricked into running malicious code into their web browser. The attacker sends malicious code to the victim who then has to paste this code into the browser to execute it. For this type of XSS to be successful the victim has to take multiple steps provided by the attacker.
In the context of bug bounty, Self XSS is often also used to refer to XSS vulnerabilities that exist in a place where only the attacker themselves is able to trigger them, thus rendering it impossible to affect other users and execute an effective attack. Because of this near zero impact this type of vulnerability is often rejected.
Impact
When an XSS attack is successful the victim can be fully compromised. The attacker will often try some of the following:
- Steal session cookies. With the session cookies the attacker can impersonate the victim and access any of his information.
- Steal login credentials.
- Gain access to sensitive information.
The impact of the different types of XSS can be similar to each other if successful. Stored XSS is considered to be the most dangerous type of XSS as it affects many users. Also for the other types of XSS to be successful user interaction is necessary. This extra interaction makes reflected and DOM based less severe attacks.
Preventing XSS
There are a few things that can be done to prevent XSS from occurring on a website.
Filter input:
- If a user submits a URL that will be returned in responses, validate that it starts with a safe protocol such as HTTPS.
- Validating that input contains only an expected set of characters.
- Create a list of safe input and don’t allow anything not on this list.
- Encode data on output, for instance by URL encoding the input data when it is displayed to avoid it being interpreted as executable content by the browser or application.
Mitigating impact
Cookie flags
The httponly and secure flags can be used to protect session cookies against XSS.
XSS attacks are often aimed at stealing session cookies to gain access to a victim’s information. If the session cookie is set with a httponly flag it is protected from being accessed using JavaScript.
The secure flag is used to make sure that the cookie can only be transmitted via a secure connection like https. The browser will never send the cookie using plain HTTP.
Content security policy
The content security policy, or CSP, is a HTTP response header that helps detect and mitigate certain attacks including XSS. CSP makes it possible to restrict how resources such as JavaScript or anything else that the browser loads. The CSP can also mitigate attacks by specifying the domains that should be considered trusted sources. The browser will only execute these trusted scripts and ignore all other scripts.
We hope you enjoyed our blog on XSS! Stay tuned for our next blog on Insecure Direct Object Reference (IDOR) vulnerability!
More information
