Cross-site scripting (XSS) is a very common vulnerability that allows malicious actors to execute malicious client-side scripts within user's browsers. This client-side script execution could lead to the defacing of the website and the theft of user data, e.g. the application authorization tokens stored in cookies.
tCell's app firewall monitors for XSS attack attempts and can be used to block the attackers; the browser agent monitors the DOM of a user's browser for successful XSS attacks, and tCell uses CSP to prevent data loss (and other compromises) that may result from these attacks. tCell also notifies the designated people in an organization of the XSS event and provides them the necessary details to quickly address the vulnerability.
An XSS attack occurs when a malicious actor injects client-side scripts and/or HTML into a web page for execution by the web browser of another user. There are three common types of XSS attacks: reflected, persistent and DOM based.
- A reflected XSS attack requires a user action that contains a malicious script for each execution of that script.
- A persistent XSS attack consists of permanently adding a malicious script to the vulnerable page, and having that script load every time a user visits it.
- A DOM based XSS attack occurs in the browser, often delivered via a malicious value in the URI fragment and does not involve the web server.
One of the most common XSS attacks, if successful, allows a malicious actor to steal a user’s application authorization tokens stored in cookies and then access the application as that user. The actor will assume that user’s privileges and will be able to act as that user, as long that specific action does not require additional security verification such as a two-factor key or a password.
The security best practice to avoid being vulnerable to XSS is to escape certain characters by using various character encoding techniques and always validating input. OWASP’s XSS Prevention Sheet is a great resource to learn the fundamentals of how to prevent XSS through best coding practices.
Most commonly, a malicious actor would use an application security scanner to scan an application for XSS vulnerabilities. The actor would also spend the time to manually discover all of the application’s parameters in the URL, header, and body, and then modify them to test for XSS vulnerabilities using techniques that are more sophisticated than the security scanner.
tCell protects against XSS attacks in three ways.
tCell's App Firewall running in the application or web server can detect requests being used to discover or exercise XSS vulnerabilities. This will engage the suspicious actors functionality to prevent the attacker from continuing.
Content Security Policy (CSP) is an industry-standard layer of security, driven by the W3C, that mitigates the risks of many types of content injection attacks. CSP's main focus is around preventing Cross Site Scripting (XSS) and script injection attacks through a whitelist approach. tCell gives you the tooling to setup, monitor and enforce your CSP through advanced tooling.
tCell assists in configuring CSP through monitoring (collection of CSP violation reports) and upfront configuration. The tCell console allows you to create and configure your CSP both through the policy editor and while monitoring your app via the dashboard.
Read the CSP Configuration guide for more details
For inline script protection, tCell provides a JS Agent to detect unexpected scripts present in the browser DOM. We do this by automatically inserting a script into the header of each page of your application. This allows us to see all of the executed scripts and then to determine which scripts are XSS attacks. The default CSP configuration allows inline scripts to execute. The JS Agent can detect and report on malicious DOM activity that is not covered by the CSP.
Inline script events will appear in the Inline Scripts (XSS) view under the Events menu. You can add expected scripts to your policy through the Inline Scripts event view or the overall Policy editor views under Settings -> Policies -> JSAgent.
Read the JS Agent Configuration guide for more details.