DOM data manipulation (DOM-based)

[ser-storchak]

The application may be vulnerable to DOM-based DOM data manipulation. Data is read from window.name and written to the 'name' property of a DOM element via the following statement:
• window.name= window.name.replace(NG_ENABLE_..., "" )
Note: The name of the current window is a valid attack vector for DOM-based vulnerabilities. An attacker can directly control the name of the targeted application's window by using code on their own domain to load the targeted page using either window.open() or an iframe tag, and specifying the desired window name.

[gkalpak]

@ser-storchak, what do you mean by "written to the 'name' property of a DOM element".
What DOM element are you referring to ?

[ser-storchak]

if (window && NG_ENABLE_DEBUG_INFO.test(window.name)) {
  config.debugInfoEnabled = true;
  window.name = window.name.replace(NG_ENABLE_DEBUG_INFO, '');
}

if (window && !NG_DEFER_BOOTSTRAP.test(window.name)) {
  return doBootstrap();
}

window.name = window.name.replace(NG_DEFER_BOOTSTRAP, '');
angular.resumeBootstrap = function(extraModules) {
  forEach(extraModules, function(module) {
    modules.push(module);
  });
  return doBootstrap();
};

This error is discovered security scanner Burp Suite Pro

[gkalpak]

I still don't get what the problem is. Can you provide more info ?
There is not DOM operation directly related or using the window's name.

[alex89romanov]

@gkalpak thank you for your time/help,
Problem is with the Security team, they are saying that application may be vulnerable to DOM-based DOM data manipulation.
We explained for them that the code is clean & there is no security risks about it, we even quoted the following https://goo.gl/qe0LxG (Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.)
They still say that this is a security risk & we have to fix it.
So far we don't understand the problem & we were trying to see if anyone can help us with it.

Thanks

[gkalpak]

Couldn't the security team explain the problem ? 😃

TBH, I can thing about two ways that would let a malicious attacker affect a site's behavior/appearance (not sure if it counts as defacing, but still):

1. A user visits malicious1.com, which prepends the window name with NG_ENABLE_DEBUG_INFO!.
   Then, in the same window, the user visits your site. Because of the window name, Angular will load your site with debug info enabled, which negatively affects its performance.
2. Similarly, a user visits malicious2.com, which prepends the window name with NG_DEFER_BOOTSTRAP!.
   Then, in the same window, the user visits your site. Because of the window name, Angular will defer the bootstrapping until your app calls angular.resumeBootstrap(). Since you app is not actually configured to do that, bootstrap will never get resumed and effectively Angular will not work on your app.

/cc @rjamet

[koto]

Making security-relevant decision based on window.name would be a vuln (because window.name can be changed cross-origin). That said, 1. and 2. from the answer above don't seem too scary - you can make an Angular site run slow or stop running, when opened in a tab attacker controlled at some point. Meh.

[rjamet]

Same thoughts as @koto for me. 2 gives an attacker the ability to open a link to a non-working version of your app, which doesn't sound great but has little impact. 1 allows linking to debug-enabled apps, and as far as I understand from https://docs.angularjs.org/api/ng/provider/$compileProvider#debugInfoEnabled, Angular's debug mode should not reduce security or change behavior ?

[gkalpak]

debugInfo can only impact performance (negatively). So, if the user has visited a malicious site, it can make your site appear broken or less performant.

These are not security vulnerabilities, but can hurt your "image". Nothing critical, but if we could avoid it (or help developers prevent it for their apps) that would be cool.