Potential DOM XSS vulnerability identified by static analysis tool

[Matt Steele]

My company utilizes a static analysis tool to scan source code for security vulnerabilities. The tool is called Fortify and is maintained by HP:
http://www8.hp.com/us/en/software-solutions/static-code-analysis-sast/index.html

Recently, this tool began reporting a DOM XSS vulnerability in angular.js. The specific issue appears to be in the undocumented `$browser.url` service: https://github.com/angular/angular.js/blob/d8d30ce67666bb15d36ee7b9cf903fe94cad5942/src/ng/browser.js

The source is identified as the store of `window.location` on this line:
https://github.com/angular/angular.js/blob/d8d30ce67666bb15d36ee7b9cf903fe94cad5942/src/ng/browser.js#L124

The sink (where potentially tainted data causes an unvalidated redirect) is writing a raw String to `location.href` here:
https://github.com/angular/angular.js/blob/d8d30ce67666bb15d36ee7b9cf903fe94cad5942/src/ng/browser.js#L156

I've found that wrapping this function call in `window.encodeURIComponent` seems to quiet the tool.

I'm not a security expert, but here's some information on DOM XSS I've found:
http://sec.omar.li/2012/05/overview-of-dom-xss.html
http://open.bekk.no/owasp-top-10-for-javascript-a2-cross-site-scripting-xss
http://stackoverflow.com/questions/1822598/getting-url-hash-location-and-using-it-in-jquery

So, I have three questions:
1. Has anyone else encountered this?
2. Should this be considered an exploitable vulnerability?
3. Is this worth submitting a PR to the AngularJS source?

This is of particular importance to me because my company halts the deployment of any applications that have vulnerabilities like this identified.

[Sander Elias]

Hi Matt,

Let try to answer your concerns.

1. No, I have not.
   
2. Only if you don't trust AngularJS.
   
3. Yes, While I do not thing this is a security issue, it might be an issue that is simple to fix, and don't throw up tools like fortify any more is a plus.

Let me expand a bit on #2. The tool like you are using is normally use to (dynamically) check scripts you have to include for 3rth party stuff (ads/social stuff mostly). You don't want any of those scripts to manipulate things like the history. However, in the way Angular gets used mostly, history manipulation might just be what you need. You even want redirect your app to some other location, this is actually quite common.

On the security site of things. Basically, if you insert a single 3rth party script, you are screwed. If there is an browser-plugin, you are screwed. If you have users, (you know the one, with the username/password on a sticky, in view!) you are ...
There is no such thing as a secure client-side app. That is including wep-app's who might be even a tad more insecure. But it is also including ALL kind of other apps. Some suggest that native apps are more secure, but thats not true.. If you expose a data-channel from your server to the outer-world, you better secure that rigorously.  And that's about what you can do.

All the above does not mean you can throw your hands in the air, and neglect all the security stuff above, you need all of that, otherwise you are putting out really low hanging fruits.

Regards

Sander

[Patrick Woo]

Hey Matt,

I'm actually facing the same issue as well with Fortify scans, has there been a resolution on this or is this a concern?

[Matt Steele]

After working with HP we believe some of this was caused by an improper parsing algorithm inside Fortify.

If you have the opportunity to update to the latest rule pack, it appears to have resolved all our issues and does not report any violations we're concerned with. You might want to open a support ticket with Fortify for more details.

--
You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/dK-S20SXQRg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Patrick Woo]

Hey Matt,

Really appreciate the quick feedback and will definitely update to the latest rule pack!

Thanks!