Cross Site Scripting (XSS) is a widespread vulnerability that affects many web applications. XSS attacks consist of injecting malicious client-side scripts into a website and using the website as a propagation method.

The danger behind XSS is that it allows an attacker to inject content into a website and modify how it is displayed, forcing a victim’s browser to execute the code provided by the attacker while loading the page.

XSS is present in about two-thirds of all applications.

Generally, XSS vulnerabilities require some type of interaction by the user to be triggered, either via social engineering or via a visit to a specific page. If an XSS vulnerability is not patched, it can be very dangerous to any website.

Examples of XSS Vulnerabilities

Imagine you are on your WordPress wp-admin panel adding a new post. If you are using a plugin with a stored XSS vulnerability that is exploited by a hacker, it can force the browser to create a new admin user while in the wp-admin panel or it can edit a post and perform other similar actions.

An XSS vulnerability gives the attacker almost full control of the most important software of computers nowadays: the browsers.

Last year, our research team disclosed a stored XSS vulnerability in the core of WordPress websites. Remote attackers could use this vulnerability to deface a random post on a WordPress site and store malicious JavaScript code in it.

Types of XSS

According to OWASP, there are 3 types of XSS:

1. Reflected XSS:

   The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser.

   Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.

2. Stored XSS:

   The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered high or critical risk.

3. DOM XSS:

   JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.

   Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM-node replacement or defacement (such as Trojan login panels), attacks against the user’s browser such as malicious software downloads, keylogging, and other client-side attacks.

Reducing the Risks of XSS

There are technologies like the Sucuri Firewall designed to help mitigate XSS attacks. If you are a developer, here is some insight on how to identify and account for these weaknesses.

How to Prevent Broken Access Control

Preventive measures to reduce the chances of XSS attacks should take into account the separation of untrusted data from active browser content. OWASP gives some practical tips on how to achieve it:

• Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework’s XSS protection and appropriately handle the use cases which are not covered.
• Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet ‘XSS Prevention’ has details on the required data escaping techniques.
• Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context-sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet ‘DOM based XSS Prevention’.
• Enabling a Content Security Policy (CSP) is a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks). I have also written a post about Content Security Policy best practices if you want to learn more about this topic.

8. Insecure Deserialization

Note: OWASP informed that this security risk is added by an industry survey and not on quantifiable data research.

Every web developer needs to make peace with the fact that attackers/security researchers are going to try to play with everything that interacts with their application–from the URLs to serialized objects.

In computer science, an object is a data structure; in other words, a way to structure data. To make it easier to understand some key concepts:

• The process of serialization is converting objects to byte strings.
• The process of deserialization is converting byte strings to objects.

Example of Attack Scenarios

According to OWASP, here are some examples of attack scenarios:

Scenario #1: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.

Scenario #2: A PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other state:

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
	

An attacker changes the serialized object to give themselves admin privileges:

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
	

One of the attack vectors presented by OWASP regarding this security risk was a super cookie containing serialized information about the logged in user. The role of the user was specified in this cookie.

If an attacker is able to deserialize an object successfully, then modify the object to give himself an admin role, it again. This set of actions could compromise the whole web application.

How to Prevent Insecure Deserializations

The best way to protect your web application from this type of risk is not to accept serialized objects from untrusted sources.

If you can’t do this, OWASP provides more technical recommendations that you (or your developers) can try to implement:

• Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
• Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
• Isolating and running code that deserializes in low privilege environments when possible.
• Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
• Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
• Monitoring deserialization, alerting if a user deserializes constantly.

Conclusion

In this post, we tackled OWASP Top 10 vulnerabilities number 7 and 8: cross-site scripting (XSS) and insecure deserialization. Soon, we will follow up with the final two vulnerabilities.