Handsontable XSS security flaw – what we’ve done to protect your data
We’ve updated Handsontable to fix the security issues recently found in the audit carried out by Securitum.
What they discovered
During their investigation, Securitum discovered an XSS (Cross-site scripting) vulnerability that affected all Handsontable versions prior to 8.2.0. The attack vector included an ability to inject a malicious code into some imperfectly sanitized components.
Medium severity threats were found in the
stripTags method and in the
strip_tags function mentioned in the documentation, inside an example. They were responsible for removing HTML tags.
In both cases, the vulnerability was mainly related to the fact that there was no recursion. All nested tags were skipped during the stripping process.
The audit also found low severity threats in the copy and paste plugin and the context menu. There was a risk that the user could copy the malicious code from another place, paste it inside Handsontable and run. The context menu gave a possibility to inject harmful code into the configuration.
Is my application safe?
XSS attacks are dangerous for end-users mostly. They do little or no harm to the application infrastructure.
The attacker would need to first compromise the security of your system, and only then inject code that could be sent to:
- damage their browser or system
- misdirect or steal a session cookie.
To make your application safer we recommend an update to Handsontable 8.2.0.
What can I do about it?
This way, the attacker can make an unaware user run the harmful script. The HTML tags prone to become vectors of the infection include:
Handsontable is constantly being developed with due diligence when it comes to security. But we can’t always fully predict how it’s used inside the applications and pages you work on. To stay safe, we highly recommend you follow general principles to oppose XSS attacks. Some of the guidelines include:
- keeping the development team aware of the issue by providing up-to-date training and recommendations.
- sanitizing the HTML input with a library of your choice; we use DOMPurify.
- using Content Secure Policy (CSP), which helps to mitigate the risk.
- setting the HttpOnly flag for cookies.
Suggestions about improving security are easy to find. For instance, the Open Web Application Security Project (OWASP) offers a cheat sheet with crucial steps to keep your application safe against XSS attacks.
Apart from general guidelines, we recommend using Handsontable methods that are focused on security. If the end-user can modify dynamic elements like headers, context menu items, or HTML cell renderer, we want to be sure we sanitized all potentially vulnerable content.
Within Handsontable, we offer two helpers you can use in your implementation:
Handsontable.helper.stripTags, which removes any HTML tags from the passed string,
Handsontable.helper.sanitize, which removes unwanted parts according to the passed DOMPurify’s configuration to sanitize text the way you need. By default, it leaves HTML tags but removes any potentially dangerous attributes.
In case end-users need to be able to access unsanitized content, you can create a custom cell renderer with no security. It’s doable but risky, so we don’t really recommend it. An example of such an unsafe renderer is our
htmlRenderer that is not sanitized since sanitization would break its functionality.
Reach out when in doubt
If you need more information about this security flaw, drop us a line at firstname.lastname@example.org.
We want you to feel safe using our tools, so delivering secure code is on top of our list and we’re more than happy to answer all your questions and concerns.