Angular Security Part 3 – proactive XSS protection
with CSP

The last post was about security vulnerabilities that you can proactively mitigate with iframe sandbox. But not all embedded content only has a practical purpose – sometimes it simply provides a bit of fun. You’re just about to leave the online store when a cheerful yellow squeaky duck suddenly appears on your screen. Your favorite online store has probably included this as a little gimmick so that you don’t leave the store yet and maybe buy something after all. Well, you can let a squeaky duck swim onto your screen…

The story continues

The attackers are not giving up and are now turning their attention to the website’s other dependencies. They are particularly targeting the squeaky duck generator module, which has long been neglected and is full of security vulnerabilities – yet it is essential for the website. A new development of the module is out of the question, and the use of <iframe> is not possible for technical reasons. The attackers discover that an XSS vulnerability for the module has been listed in the CVE database for six months. They try to exploit this, but fail due to the already implemented Content Security Policy (CSP), which blocks the attack.

Content Security Policy (CSP)

You are a developer: You want to better protect your website against XSS attacks and rely on Content Security Policy (CSP).

CSP are additional rules that are transmitted via the header fields of each HTTP request. They influence the behavior of the web browser with regard to JavaScript execution and the use of other external resources. A good starting point for a policy would be, for example:

Content-Security-Policy

default-src 'self'; style-src 'self'; script-src 'self' 'qualityminds.com';

What is happening here? We see a series of settings separated by semicolons. These are composed as follows: <Direktive> <Domain/Schlüsselwort>.

1. Directives

CSP works with a series of directives that determine which resources may be loaded and executed. Common directives are

• default-srcIs the default source for resources if they are not specified by other directives.
• script-src: Controls the sources from which the scripts can be executed.
• style-src: Determines from which sources the styles can be used.
• img-srcDefines the sources from which images can be loaded.
• font-src: Controls the sources of fonts.
• connect-src: Specifies the origins to which the application can send network requests (AJAX, WebSockets, etc.).
• frame-srcDefines the sources for <frame> and <iframe>.

2. Keywords

Directives can be set to specific domains, but there are also keywords that can be used:

• 'self'Refers to the current origin and allows resources from the same domain to be loaded.
• 'none'Blocks all resources for this directive.
• 'unsafe-inline'Enables inline scripts or styles. Use this with caution as it can compromise security.
• 'unsafe-eval'Allows the use of eval() and similar functions. Also risky.
• 'strict-dynamic'Allows the dynamic creation of scripts, but only from trusted sources.

Let’s look again at the example from earlier with the newly acquired knowledge:

• default-src 'self'; For all directives not mentioned in the policy: only load your own JavaScript.
• script-src 'self'; Only trust JavaScript from your own source.
• style-src 'self' 'qualityminds.com'; Trust CSS styles from your own source or from “qualityminds.com”. To include subdomains, style-src ‘self’‘*.qualityminds.com’; is again required.

Setting up CSP in nginx

The application written in Angular is often brought to the customer using the nginx web server. If a special configuration is necessary, this requires an adjustment in the nginx configuration file at /etc/nginx/sites-available/ on the Linux server. The following line is added:

add_header Content-Security-Policy "default-src 'self'; style-src 'self'; script-src 'self' 'qualityminds.com';"

After the server restart, the CSP headers with the policy changes are automatically downloaded for each user.

Setting up CSP in Angular

Not a fan of server configuration or it’s not your area of responsibility? There is a way to define CSP headers in Angular. This can be done using the <meta> tag in Angular’s index.html file:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; style-src 'self'; script-src 'self' 'qualityminds.com';">

Stay tuned!

Updates are not enough

As an attacker, you know that many website operators rely on third-party modules and that these often have vulnerabilities. You are happy that you can still find points of attack despite sandboxing and CSP.

Next post

Your squeaky ducky generator, which is vulnerable to XSS attacks, has just been saved! The attackers cannot execute their own JavaScript code with it. But the next challenge is sure to come. Find out in the next article how you can secure your web application even better against attacks. Stay tuned!