How can a Content Security Policy prevent XSS and other vulnerabilities?

Keeping code safe in the era of cybercrime is no small feat, and many age-old tactics remain just as effective today as they were 20 years ago. When it comes to web hacking, modern browsers have made significant strides in security. Things like a content security policy can prevent many of the oldest tricks that remain surprisingly common today.

Injection attacks have been around since the early days of the internet and continue to be a problem in 2020. Here’s a closer look at the infamous XSS vulnerability, and how implementing an airtight content security policy can go a long way to protecting a site against being a vector for malicious code.

What is an XSS vulnerability?

Cross-site scripting (XSS) is an attack that leverages a common vulnerability in web applications. In this attack, a hacker uses the web application to transmit malware to another user through code that is “injected” into the website itself. That malware can perform many different actions, but the most common is to steal the cookies of other users.

Cookies theft allows hackers to pose as their victims when accessing a site. To steal them, a JavaScript code is inserted into the site via a form capable of reading HTML – such as an item listing, a web comment, or a search bar. Anyone who accesses the link to the comment, listing, or search result with the malicious code embedded will automatically receive the malware on their computer.

That malware then extracts the cookies from a user’s session, sending it to the hacker. The hacker can load those cookies into his or her browser. Once on the targeted site, the site will authenticate the hacker as his or her target. From there, it’s just a matter of finding the user’s billing information or changing the password on the account.

XSS has been around since the early days of HTML. It’s been used against email, e-commerce sites, online banking, and auction sites. The problem was once so widespread that even Facebook, Twitter, and YouTube have been among some of the sites affected by them. Yet, despite significant advances in security, they continue to be a problem. It is estimated that 84 percent of all websites remain vulnerable to jQuery XSS in 2019.

How to use a Content Security Policy to protect against XSS

A Content Security Policy (CSP) is a layer of security specifically designed to detect and mitigate injection attacks, including those done with XSS. It makes it significantly more difficult for a hacker to inject malicious code to siphon data or cookies from a site’s legitimate users.

With a CSP, a developer:

• Specifies allowed resources and their origins using a safe list: In other words, scripts and codes that are needed to run the web application are allowed – from specific origins. Everything else is blocked.

• Defines the CSP directive: By default, this policy will be default-src but that can be changed. Several directives exist to control specific elements of the CSP as necessary.

• Determines whether inline scripts or eval() are allowed: By default, a CSP header blocks both inline scripts and the function eval() as malicious.

• Determines whether style attributes are permitted in HTML: Since CSS can be exploited, CSP defaults do not allow blocks or the attribute within HTML.

• Gains the ability to report policy violations to the server: This helps track instances of misuse.

A CSP is typically implemented on the server and that process may vary considerably. However, if a service provider doesn’t offer control over the server’s configuration, it’s still possible to enable CSP in the site’s header using meta tags.

Also, a developer can scan and test their website for the use of HTTP security headers to determine current status, or use the CSP Evaluator as a tool for hardening a CSP configuration.

Why use a Content Security Policy?

Using a CSP is a good idea for any website involving complex web applications, login functionalities, and user cookies.

1. XSS is ubiquitous and damaging

XSS takes advantage of the way browsers are built, particularly the fact that browsers can’t distinguish between legitimate code and injected code on their own. It’s effectively a back door to access user data and other sensitive information.

2. It provides support against difficult-to-spot XSS vulnerabilities

Any web application relying on cookies to support login functionalities may be vulnerable to XSS, even if it’s otherwise well-designed. As hackers are tenacious, a seemingly secure codebase may still have other vulnerabilities that developers don’t spot.

3. A CSP supports other security best practices

CSP helps enforce security best practices by locking down many actions and reducing the list of origins. As a result, it works best in combination with other security best practices like template systems, vulnerability scanning, and manual security reviews. 

Don’t let the site stay unsecured

With all the emphasis on business and DevOps security, many people might overlook the fact that websites still can and do get hacked. XSS is an age-old vulnerability that can still hit sites without a competent content security policy in place. Fortunately, implementing a CSP is relatively easy. Take steps now to ensure that the website is as secure as the rest of the business.