Last updated at Thu, 11 May 2023 01:39:41 GMT
In two recent cyberattacks against an airline and a large e-commerce ticketing company, thousands of customers had their personal and financial data compromised through a malicious strategy called cross-site scripting (XSS).
XSS isn’t new, but its impact and visibility are both growing. The most famous recent example is Magecart, a group linked to both of the attacks referenced above. Web applications are a key point of vulnerability for data breaches. Here’s what you need to know to protect them from XSS attacks.
What is cross-site scripting (XSS), and why is the problem getting worse?
An XSS attack involves an attacker injecting malicious scripts into a web page or application. When the victim visits the page or application, the code is executed. For example, Magecart inserts scripts that skim payment card data when the user makes a purchase.
The fact is, protecting a website just isn’t as simple as it used to be. Web applications are increasingly targeted due to their complexity and how difficult they are to monitor. It’s great that organizations can now give their web and mobile visitors a rich, varied and interactive experience that spans multiple devices, but this ability makes things far more complicated for the IT security team. Gone are the days when locking down the server was enough—now, you also have to pay attention to browsers, web and mobile applications, and all of their components.
There are two primary methods of deterring XSS attacks, but they each come with their own challenges and shortcomings.
1. Preventing XSS attacks through filtering and sanitation
The goal of filtering is to prevent malicious scripts from getting onto the website in the first place. Since the malicious code comes from a client-side source such as a user-submitted form or a compromised cookie, you pass all external data through a filter. Simple, right? Unfortunately, filtering does come with some obstacles.
As web applications grow more complex, they increasingly rely on third-party components—and these components are often the most vulnerable. In the case of the ticketing company’s hack, malicious JavaScript was injected into a third-party component. Even though companies are becoming stricter about these components, they still struggle to filter them all. And if your web application security efforts find vulnerabilities, it’s difficult to get the third party to fix it.
If your website includes user submissions such as comments, reviews, profiles, or product descriptions, filtering will be a challenge. For example, another e-commerce organization has regularly suffered from small-scale XSS attacks because it allows users to post complex descriptions that include JavaScript. With thousands of users submitting information, it’s almost impossible to sanitize completely using filtering.
Finally, filtering usually requires a team of people to handle the heavy workload. When your human resources are stretched thin, manually maintaining a filter may not be possible.
2. Preventing XSS attacks with a Content Security Policy
A Content Security Policy (CSP) involves using HTTP headers to whitelist the sources that will be trusted by your web application. All others will be blocked. CSP is highly effective in preventing XSS attacks, but like filtering and sanitation, implementing and maintaining it has its drawbacks.
The first problem with CSP is that it assumes your web applications are static, when in fact they change constantly. If you use CSP and fail to update it for new sources or dependencies, your site will break. In addition to being dynamic, your website is also complex. While you once had a browser talking to a single server, most sites now include analytics, ads, monitoring, and other third-party components. You’re going to wind up with some very complex CSP headers.
So, who is responsible for making sure your CSP will prevent each new XSS attack without crashing your site? The developer has the arduous task of figuring out every resource the website accesses and manually configuring the CSP to work with it. For an inexperienced member of the team, they may simply not have the skills to implement a CSP, since even the best developers can find CSP to be error-prone and difficult to maintain.
Furthermore, those developers who wrote the code for the website probably won’t be the ones managing it. These people may not have visibility into all the dependencies and could end up breaking the website as a result. It’s especially difficult to gain visibility into dependencies if you have third parties developing additional solutions.
CSP is challenging at first glance. But, with the right solution, it can be made much easier. The key is utilizing CSP's reporting mechanism to facilitate communication between devs and security engineers. With data, CSP can be refined in the stage environment, so that when deployed, the app has an updated CSP. Discussions on what resources are okay for the app, can happen with full transparency between the teams prior to updating the CSP and deploying the new update to production. Let’s talk about what you can do about it.
Prevent XSS attacks through visibility and flexibility
To find a problem, you have to be looking for it in the right place. That requires deep knowledge of what the app is actually doing and its potential attack points. Know each app’s components, their status, and how they communicate, and monitor the data being accessed by the app.
In order to effectively use CSP, be data-driven. tCell, our cloud WAF and RASP tool integrates seamlessly with CSP in order to collect application behavior and uses that data to recommend a policy you can create with a few clicks. In addition, the suggested policy updates provide an excellent way for development and security teams to discuss risks in third-party dependencies, and have an aligned view of benefits vs. risks. Not only does this provide an elegant technical solution, but tCell can be helpful in a collaborative security culture, which is vital for any company where security is important.Your application security solution should be able to keep pace with change and innovation in the app ecosystem.
There are solutions that can help you maintain transparency into your apps and dynamic policy. tCell by Rapid7 on the Insight platform enhances web application security at every level—from browser to server. tCell provides a web-based solution that allows you to automatically get real-time visibility into all web resources used by an application with no coding required. In addition, tCell allows you to create fine-grained blocking rules to disallow untrusted resources from a high-level configuration user interface without having to manually edit HTTP headers.
