Fortify Scan throwing a critical vulnerability

[yiddo97]

Had an issue with the Fortify scans of our application, where a critical vulnerability was logged due to XSS : Dom.
The exact code causing the issue wasn't located and instead the issue was located in the minified build JS file. Upon further perusal, I located the issue in the 'Axios' library.
Has anyone faced a similar problem before or is there a patch available for this?

Thanks!

[bluSCALE4]

To help elaborate a bit, the helper in question is axios\lib\helpers\isURLSameOrigin.js.

  utils.isStandardBrowserEnv() ?

  // Standard browser envs have full support of the APIs needed to test
  // whether the request URL is of the same origin as current location.
  (function standardBrowserEnv() {
    var msie = /(msie|trident)/i.test(navigator.userAgent);
    var urlParsingNode = document.createElement('a');
    var originURL;

    /**
    * Parse a URL to discover it's components
    *
    * @param {String} url The URL to be parsed
    * @returns {Object}
    */
    function resolveURL(url) {
      var href = url;

      if (msie) {
        // IE needs attribute set twice to normalize properties
        urlParsingNode.setAttribute('href', href);
        href = urlParsingNode.href;
      }

      urlParsingNode.setAttribute('href', href);

      // urlParsingNode provides the UrlUtils interface - http://url.spec.whatwg.org/#urlutils
      return {
        href: urlParsingNode.href,
        protocol: urlParsingNode.protocol ? urlParsingNode.protocol.replace(/:$/, '') : '',
        host: urlParsingNode.host,
        search: urlParsingNode.search ? urlParsingNode.search.replace(/^\?/, '') : '',
        hash: urlParsingNode.hash ? urlParsingNode.hash.replace(/^#/, '') : '',
        hostname: urlParsingNode.hostname,
        port: urlParsingNode.port,
        pathname: (urlParsingNode.pathname.charAt(0) === '/') ?
                  urlParsingNode.pathname :
                  '/' + urlParsingNode.pathname
      };
    }

    originURL = resolveURL(window.location.href);

It all stems from setAttribute but as far as I can tell, the anchor is only used as a url api and should be exposed to the user.

[emilyemorehouse]

0.19.0 has a fix and has been released

[bluSCALE4]

@emilyemorehouse are you sure? I checked source and I still see setAttribute being used in the file mentioned above.

urlParsingNode.setAttribute('href', href);

[correamarques]

@emilyemorehouse I'm having same problem with Fortify, the error was: Cross-Site Scripting: DOM [0] at isURLSameOrigin.js#26 [1]

if (msie) {
  // IE needs attribute set twice to normalize properties
  urlParsingNode.setAttribute('href', href);
  href = urlParsingNode.href;
}

Can you open this issue again?

[0] https://vulncat.fortify.com/en/detail?id=desc.dataflow.java.cross_site_scripting_dom#JavaScript
[1] https://github.com/axios/axios/blob/master/lib/helpers/isURLSameOrigin.js#L26

[jmccormick28]

@correamarques was your Fortify scan ☝️ against version 0.19.0 that @emilyemorehouse said had a fix for the finding?

[nathanmmiller]

I'm seeing the same issue, also with Fortify Scan, same lines of code, in version 0.19.0 of axios. Can we reopen this issue @emilyemorehouse?

[mkotsollaris]

snyk also complains about this (newer 0.19 version):

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). The .setAttribute method allows unvalidated data from a user to be inserted, this could be leveraged by an attacker to execute malicious JavaScript by providing a url such as https://github.com/axios/axios?<script>alert("hello")</script>.

[Fun-333]

Can this XSS issue be triggered in what scenario？How to avoid this problem?

[AleksueiR]

Guys from Snyk say it's a false positive.