2

I mainly audit web applications and provide the companies with security countermeasures and recommendations. Currently, I have an issue with giving a correct recommendation when it comes to AngularJS Sanitize function against XSS protection. I have doubts to say that it's OK or to recommend that output encoding shall be enforced at the server-side.

Can anybody help me with this issue or is able to clarify the difference?

schroeder
  • 123,438
  • 55
  • 284
  • 319
sgres
  • 129
  • 2
  • 8
  • 2
    its pretty much a rule of thumb that you should do any kind of sanitation on the backend. – TheHidden Feb 01 '18 at 11:12
  • that script's not that great, relying on white-lists and tag rules. – dandavis Feb 01 '18 at 12:13
  • A quick Google search shows more than one thing that could be referred to as AngularJS Sanitize, and there are multiple versions of Angular. Are you asking about one specific library, or the concept of client-side sanitation in general? – gatkin Feb 01 '18 at 13:53
  • 1
    @gatkin My main issue is with versions below 2.0. In the documentations, it is mentioned as "One example of such a context is rendering arbitrary content via the ngBindHtml directive. If the content is provided by a user there is a chance of Cross Site Scripting (XSS) attacks. The ngBindHtml directive will not render content that is not marked as safe by $sce. The ngSanitize module can be used to clean such user provided content and mark the content as safe." https://docs.angularjs.org/guide/security and https://docs.angularjs.org/api/ngSanitize/service/$sanitize. Thanks :) – sgres Feb 01 '18 at 14:51

1 Answers1

1

tl;dr: Encoding should be done at the time the data is being used in context - when the code is composing HTML, javascript, etc from untrusted data - that's true whether you are composing on the server or client. At that point you know what parts are data, and what the encoding context is. You should leverage binding (ng-bind) in Angular for context specific encoding. The AngularJS Sanitize function is useful when you need to "sanitize" a hunk of untrusted HTML.

Details: Its good to be careful when the term "sanitize" is being used, because different libraries use it differently - it can mean validation, canonicalization, simple encoding, parsing and encoding.

The AngularJS Sanitize function "sanitizes" inputs by parsing the HTML into tokens. All safe tokens (from a whitelist) are then serialized back to properly encoded values. In this way it behaves similarly to the OWASP HTML Sanitizer Project and the older OWASP Antisamy project.

See https://odetocode.com/blogs/scott/archive/2014/09/10/a-journey-with-trusted-html-in-angularjs.aspx for more information on using the library.

This is a fine way to encode untrusted input if you don't have the luxury of composing the HTML, javascript, or URL from its parts. However:

  • The parsing and removal of tags is more prone to being bypassed - I don't know of any current issues
  • It modifies the HTML to remove unrecognized tags, which can sometimes be fragile
  • It has to make assumptions about whether the underlying content is encoded
  • The tag support will be limited to the white list - however, you can decorate the $sanitize service to change the list

So where you can:

  • Encode at the time the data is being used in the context - for example by using binding.
  • Leverage the Sanitize function if you didn't compose it
  • Try to leverage CSP (Content Security Policy) as a defense in depth
Egret
  • 436
  • 3
  • 5