To bring awareness to what threatens the integrity of websites, we are continuinga series of posts on the OWASP top 10 security risks .
The OWASP Top 10 list consists of the 10 most seen application vulnerabilities:
Injection Broken Authentication Sensitive data exposure XML External Entities (XXE) Broken Access control Security misconfigurations Cross-Site Scripting (XSS) Insecure Deserialization Using Components with known vulnerabilities Insufficient logging and monitoringIn our previous posts, we explained the first six items on the OWASP Top 10 list. Today, we are going to explore items 7 and 8: cross-site scripting and insecure deserialization .
7. Cross-Site Scripting (XSS)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 VulnerabilitiesImagine 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 userwhile in thewp-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 storemalicious javascript codein it.
Types of XSSAccording to OWASP , there are 3 types of XSS:
Types of XSS Reflected XSS
:
The application or API includes unvalidated andunescaped user input as part of HTML output. A successfulattack can allow the attacker to execute arbitrary HTML andJavaScript in the victim’s browser.
Typically the user will need tointeract with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites,advertisements, or similar.
Stored XSS:
The application or API stores unsanitized userinput that is viewed at a later time by another user or anadministrator. Stored XSS is often considered high or criticalrisk.
DOM XSS:
JavaScript frameworks, single-page applications, andAPIs that dynamically include attacker-controllable data to apage are vulnerable to DOM XSS. Ideally, the application wouldnot 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 asmalicious software downloads, keylogging, and other client-sideattacks.
Reducing the Risks of XSSThere 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 ControlPreventive measures to reduce the chances of XSS attacks should take into account the separation of untrusted data fromactive 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 thelimitations of each framework’s XSS protection andappropriately handle the use cases which are not covered.
Escaping untrusted HTTP request data based on the context inthe HTML output (body, attribute, JavaScript, CSS, or URL) willresolve Reflected and Stored XSSvulnerabilities. TheOWASPCheat Sheet ‘XSS Prevention’has details on the required dataescaping techniques.
Applying context-sensitive encoding when modifying thebrowser document on the client side acts against DOM XSS.When this cannot be avoided, similar context-sensitiveescaping techniques can be applied to browser APIs asdescribed in theOWASP Cheat Sheet ‘DOM based XSSPrevention’.
Enabling aContent Security Policy (CSP)is a defense-in-depthmitigating control against XSS. It is effective if no othervulnerabilities exist that would allow placing malicious code vialocal file includes (e.g. path traversal overwrites or vulnerablelibraries 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 DeserializationNote: 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 ScenariosAccording to OWASP, here are some examples of attack scenarios:
Scenario #1 :A React application calls a set of Spring Bo
