Security Concerns in Aurelia


#1

I was curious if the core team is familiar with XSS security issues in Aurelia. Are there any plans to tighten security? https://www.blackhat.com/docs/us-17/thursday/us-17-Lekies-Dont-Trust-The-DOM-Bypassing-XSS-Mitigations-Via-Script-Gadgets.pdf#page=35


#2

Unless you’re binding to innerhtml everything in Aurelia is escaped which solves most XSS issues.

If you’re loading untrusted templates or code you’re going to have issues in any app or framework.

If you’re loading untrusted content through innerhtml you need to sanitise it. Aurelia supplies a sanitizeHtml but its recommended to use something more robust.


#3

The only Aurelia example in the linked document is:

Aurelia has its own expression language, unknown to mitigations.
With it, we can create arbitrary programs and call native functions.
The following payload will insert a new SCRIPT element with our code:

<div ref="me"
s.bind="$this.me.ownerDocument.createElement('script')"
data-bar="${$this.me.s.src='data:,alert(1)'}"
data-foobar="${$this.me.ownerDocument.body.appendChild($this.me.s)}"></div>

The only way I can see this being an issue is if you’re loading your templates from an untrusted source or your templates are getting modified before being loaded. Simply adding this to the DOM does nothing.


#4

So their example exploits can be found here https://github.com/google/security-research-pocs/tree/master/script-gadgets/repo .

If you look through their examples, you’ll notice they’re using Aurelia incorrectly. They are trusting user input, for example by binding innerhtml…
The “exploits” posted here are by design in Aurelia, and I wouldn’t even call them exploits :slight_smile:

They work for Google? I would have expected better exploits from them to be honest, especially coming from a Blackhat presentation.


#5

This was just brought up in an OWASP security training. Our instructor was praising react and had never heard of Aurelia.

I think their thinking is that a “good secure” js framework will prevent a novice from making insecure mistakes like this.


#6

I think their thinking is that a “good secure” js framework will prevent a novice from making insecure mistakes like this.

I guess this makes sense since security is hard and when you are a novice, you may have never heard of XSS. On the other hand, binding to innerHtml has its use cases (I used it once, don’t remember why exactly). So I guess we are back to the security vs features kind of dilemna.

I wonder if we could use a linter to detect binding to innerHtml and display a security warning in these cases ? This could be a good compromise.


#7

Yeah, I don’t know react very well, but he mentioned that you could override the security features with some kind of “I know what I’m doing” flag.


#8

And a beginner might be tempted to use this flag to get the code working. So I guess that if you don’t know about XSS you will do mistakes anyway.


#9

I used innerhtml just the other day so that a value converter could return text with superscript. The only other way I could think of doing this was to create a custom component specifically for displaying scientific numbers which split the output into multiple styled spans which seemed like a lot of overhead.

1.23e<sup>+14</sup>

1.23e+14


#10

You could use https://github.com/MeirionHughes/aurelia-template-lint and create a custom rule to hint about potentially dangerous usage of innerhtml. The linter could provide a warning, containing links to descriptions of XSS and how to make sure not to fall into that trap