Angular Template Injection without Quote Characters

Introduction

When you’re trying to detect XSS in an Angular application (AngularJS or Angular >2, the version doesn’t matter for this post), you’ll probably try the following possibilities:

  • You enter a basic XSS payload such as <script>alert(0);</script>
  • You find out that the developer encoded the output properly and the < > characters turn into &lt; and &gt; 
  • Your next attempt will be a client-side template injection: {{1338-1}}
  • The application displays 1337
  • From here on, it will be straight-forward: you’ll find a payload that matches the Angular version of the app and pop that alert to get a Proof of Concept.

However, in some cases, the output sanitation applies not only to characters like > and < but also encodes single and double quote characters ( ‘ will turn into &apos;, etc.)

This means that if you try to insert a payload that has quotes in it, for example:

{{constructor.constructor('alert(0)')()}}

It will turn into

{{constructor.constructor(&apos;alert(0)&apos;)()}}

At this point, your expression will trigger a syntax error and the payload will fail. 

So, what can we do about it?

When trying to avoid quotes in a payload (because it contains strings) the easiest way is to use functions that generates strings. In JavaScript, we will need to use the String object, specifically, the String.fromCharCode() method

The issue in this case (Angular applications) is that we cannot just call String.fromCharCode()in an Angular expression:

{{constructor.constructor(String.formCharCode(...))()}}

It will not work because Angular limits us to only using the properties and variables that are accessible under Angular’s scope. (More about the scope here: https://github.com/angular/angular.js/wiki/Understanding-Scopes). If Angular wasn’t stopping us from accessing objects outside the scope, we wouldn’t need to access the Stringobject. As attacker, we could just inject {{window.alert(0)}}

So what do we do when we don’t have access to the Stringobject but we still need to call fromCharCode() to generate our “alert(0)” string?

We can use this payload:

{{constructor.constructor(valueOf.name.constructor.fromCharCode(...))()}}

Let’s break it down

  • We used valueOf.name because it returns a string value. Right now, it doesn’t matter what string is returned. As long as it’s a string variable – we’re good to go. In the same way, we could use any of the following possibilities as they all generate strings:
  • Now that we have a string variable in our payload, let’s look at its constructor:
  • The constructor itself is a String object! Now, all we have to do is to add a dot character and access all of the available functions in the String object including fromCharCode

By getting to the String object in this indirect way, even though the object itself isn’t in Angular’s scope, we can create an Angular, Client-Side Template Injection payload without needing single or double quotes

And here’s our alert 🙂 without quotes.

Acknowledgements

Big shout-out goes to the folks from PortSwigger and Tomer Haddad


A Taxonomy on Brute Force Attacks

Brute force attack is a well-known technique of trial and error attempts used by attackers to gain access to unauthorized data. It can be leveraged against servers as an online attack and also against files as a local attack.

The common denominator of all these types is that the same pattern is almost always the same:

In most cases the attacker would have to know two major keys from the diagram – let’s take for example a common scenario where the attacker tries a brute-force attack on the login interface of an applicaiton in order to find the correct credentials of a certain account. The known keys would be:

  1. Something I know – In this case, the username of the account that the attacker wants to hijack.
  2. The result – On each attempt, the attacker receives an indicator of failed/successful result.

The well-known brute-force methods are:

Read more

Secure Development Lifecycle for Open Source Usage

Preface How do we adjust the SDL (Security Development Lifecycle) process for the growing use of open source in internal/external systems we develop and maintain? This is a question I hear a lot lately from our customers in some recent SDL projects we (AppSec Labs) carried out for our customers. After we did some research, […]

Hacking Android Apps Through Exposed Components

In almost every Android application, developers expose activities without sufficient protections. Exposing activities can lead to various attacks. For example, an attacker or a malicious app installed on the same device, can call those exposed activities to invoke internal pages of the application. Calling internal pages puts the application at risk of phishing by manipulating […]

Guidelines for pentesting security systems

How do you perform a security test? Ever wanted to perform a penetration test on a security system (website, application, mobile and etc.) and just didn’t know where to start? These days, companies are very concerned about the security in their applications due to the increase in the number of disclosed vulnerabilities and exploits which can […]

Password Autocomplete vulnerability and a workaround solution

Until recently, it was trivial for developers to disable the “save you password” feature implemented by all major browsers. However, in the last years, browser vendors have begun to actively discourage and prevent applications from disabling this feature. Their case is that the safest practice for users is to use a password manager, instead of having their passwords lying around on digital or physical support, where they can be exposed or stolen. Since it’s a client-side issue, they claim that the option should be given to users (and not to the developers) to disable this feature by configuring the browser itself.

Although this may be partly true, it does not take into account highly sensitive applications, which might be used on a shared computer, and which do not want to rely on the browser being properly configured (with autocomplete disabled). If this is your case, you should keep on reading.

It is now a real challenge to find a workaround that will work across all major browsers. So we came up with the following trick which detects the user’s browser version and acts accordingly:

Read more

Advanced Packet Editor – TCP/HTTP Client-Server Proxy

The Advanced Packet Editor (APE) is an open-source project for a TCP and HTTP-based proxy that allows you to intercept and manipulate communication between clients and servers.

We at AppSec Labs have taken the project, modified and improved it into a useful tool for application penetration testing.

This tool is under the GPL license (for more information: http://www.gnu.org/licenses/gpl-3.0.en.html)
Read more

headers-security-headers

Improve your Web App’s security with HTTP Headers

Over recent years, new security standards have been set by the W3C, and implemented by browser vendors. The idea was to create a set of HTTP headers that developers could use in order to add a browser-based layer of security for their web applications.

Indeed, many security problems can (or should) be remediated on the client side (e.g. Same Origin Policy), and by improving the security of the platforms it was clear that the overall security level of web applications would increase, with little regard to the actual server-side implementation.

Let’s present a quick overview of these HTTP headers:

X-XSS-Protection

Description: Enables a Cross-Site Scripting (XSS) filter in the browser that blocks the malicious reflected XSS code.

Setting: X-XSS-Protection: 1; mode=block

Supported Browsers: IE 8+, Chrome, Safari (WebKit).

Additional Information: https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

X-Content-Type-Options

Read more