org.webjars.npm:angular@1.0.0 vulnerabilities

  • latest version

    1.8.3

  • first published

    9 years ago

  • latest version published

    2 years ago

  • licenses detected

  • package manager

Direct Vulnerabilities

Known vulnerabilities in the org.webjars.npm:angular package. This does not include vulnerabilities belonging to this package’s dependencies.

Automatically find and fix vulnerabilities affecting your projects. Snyk scans for vulnerabilities and provides fixes for free.
Fix for free
Vulnerability Vulnerable Version
  • M
Incomplete Filtering of Special Elements

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Incomplete Filtering of Special Elements. The srcset attribute in an HTML <source> element can be a vector for content spoofing. An attacker can manipulate the content presented to other users by interpolating a srcset value directly that doesn't comply with image source restrictions, or by using the ngAttrSrcset directive.

Note: The ngSrcset and ngPropSrcset directives are not attack vectors for this vulnerability.

How to fix Incomplete Filtering of Special Elements?

There is no fixed version for org.webjars.npm:angular.

[0,)
  • M
Regular Expression Denial of Service (ReDoS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the $resource service due to the usage of an insecure regular expression. Exploiting this vulnerability is possible by a large carefully-crafted input, which can result in catastrophic backtracking.

How to fix Regular Expression Denial of Service (ReDoS)?

There is no fixed version for org.webjars.npm:angular.

[1.0.0,)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) due to insecure page caching in the Internet Explorer browser, which allows interpolation of <textarea> elements.

How to fix Cross-site Scripting (XSS)?

There is no fixed version for org.webjars.npm:angular.

[0,)
  • H
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). XSS may be triggered in AngularJS applications that sanitize user-controlled HTML snippets before passing them to JQLite methods like JQLite.prepend, JQLite.after, JQLite.append, JQLite.replaceWith, JQLite.append, new JQLite and angular.element.

JQLite (DOM manipulation library that's part of AngularJS) manipulates input HTML before inserting it to the DOM in jqLiteBuildFragment.

One of the modifications performed expands an XHTML self-closing tag.

If jqLiteBuildFragment is called (e.g. via new JQLite(aString)) with user-controlled HTML string that was sanitized (e.g. with DOMPurify), the transformation done by JQLite may modify some forms of an inert, sanitized payload into a payload containing JavaScript - and trigger an XSS when the payload is inserted into DOM.

PoC

const inertPayload = `<div><style><style/><img src=x onerror="alert(1337)"/>` 

Note that the style element is not closed and <img would be a text node inside the style if inserted into the DOM as-is. As such, some HTML sanitizers would leave the <img as is without processing it and stripping the onerror attribute.

angular.element(document).append(inertPayload);

This will alert, as <style/> will be replaced with <style></style> before adding it to the DOM, closing the style element early and reactivating img.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.8.0 or higher.

[,1.8.0)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). The regex-based input HTML replacement may turn sanitized code into unsanitized one. Wrapping <option> elements in <select> ones changes parsing behavior, leading to possibly unsanitizing code.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.8.0 or higher.

[,1.8.0)
  • M
Denial of Service (DoS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Denial of Service (DoS). None

How to fix Denial of Service (DoS)?

Upgrade org.webjars.npm:angular to version 1.6.3 or higher.

[,1.6.3)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). None

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.6.5 or higher.

[,1.6.5)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). The $http service allows JSONP requests with untrusted URLs, which could be exploited by an attacker.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.6.0-rc.2 or higher.

[,1.6.0-rc.2)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) through SVG files if enableSvg is set.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.6.9 or higher.

[,1.6.9)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). Browsers mutate attributes values such as &#12288;javascript:alert(1) when they are written to the DOM via innerHTML in various vendor specific ways. In Chrome (<62), this mutation removed the preceding "whitespace" resulting in a value that could end up being executed as JavaScript.

Here is an example of what could happen:

// Code goes here
var h1 = document.querySelector('h1');
h1.innerHTML = '<a href="&#x3000;javascript:alert(1)">CLICKME</a>';
var innerHTML = h1.innerHTML;
console.log(innerHTML);
h1.innerHTML = innerHTML;

The sanitizer contains a bit of code that triggers this mutation on an inert piece of DOM, before angular sanitizes it.

Note: Chrome 62 does not appear to mutate this particular string any more, instead it just leaves the "whitespace" in place. This probably means that Chrome 62 is no longer vulnerable to this specific attack vector.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.6.7 or higher.

[,1.6.7)
  • M
JSONP Callback Attack

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to JSONP Callback Attack. JSONP (JSON with padding) is a method used to request data from a server residing in a different domain than the client.

Any url could perform JSONP requests, allowing full access to the browser and the JavaScript context. This can lead to Cross-site Scripting.

How to fix JSONP Callback Attack?

Upgrade org.webjars.npm:angular to version 1.6.1 or higher.

[,1.6.1)
  • M
Arbitrary Script Injection

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Arbitrary Script Injection. Attributes were not protected via $sce, which prevents interpolated values that fail the RESOURCE_URL context tests from being used in interpolation. For example if the application is running at https://docs.angularjs.org then the following will fail:

<link href="{{ 'http://mydomain.org/unsafe.css' }}" rel="stylesheet">

By default, RESOURCE_URL safe URLs are only allowed from the same domain and protocol as the application document.

How to fix Arbitrary Script Injection?

Upgrade org.webjars.npm:angular to version 1.2.30 or higher.

[1.0.0,1.2.30)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) via the SVG <use> element. The <use> element can reference external SVG's (same origin) and can include xlink:href javascript urls or foreign object that can execute XSS. The change disallows <use> elements in sanitized SVG markup.

An example of a malicious SVG document would be:

SVG to sanitize:

<svg><use xlink:href="test.svg#xss" /></svg>

External SVG file (test.svg):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg" width="100"
   height="100"
   id="xss">
<a xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="javascript:alert(1)">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
</a>
</svg>

Here the SVG to sanitize loads in the test.svg file via the <use> element. The sanitizer is not able to parse this file, which contains malicious executable mark-up. This can only be taken advantage of if the external file is available via the same origin restrictions in place.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.5.0-rc.0 or higher.

[,1.5.0-rc.0)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) attacks involving assignment on constructor properties.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.4.10 or higher.

[,1.4.10)
  • H
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). This error occurs when $sanitize sanitizer tries to check the input for possible mXSS payload and the verification errors due to the input mutating indefinitely. This could be a sign that the payload contains code exploiting an mXSS vulnerability in the browser.

mXSS attack exploit browser bugs that cause some browsers parse a certain html strings into DOM, which once serialized doesn't match the original input. These browser bugs can be exploited by attackers to create payload which looks harmless to sanitizers, but due to mutations caused by the browser are turned into dangerous code once processed after sanitization.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.5.0-beta.2 or higher.

[,1.5.0-beta.2)
  • H
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) due to no proper sanitization of xlink:href attributes.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.5.0-beta.0 or higher.

[1.0.0,1.5.0-beta.0)
  • H
Arbitrary Code Execution

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Arbitrary Code Execution via unsafe svg animation tags.

How to fix Arbitrary Code Execution?

Upgrade org.webjars.npm:angular to version 1.4.0 or higher.

[,1.4.0)
  • M
Arbitrary Command Execution

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Arbitrary Command Execution due to the assignment functions accessing constructors functions, allowing attackers to execute their malicious code.

How to fix Arbitrary Command Execution?

Upgrade org.webjars.npm:angular to version 1.3.2 or higher.

[,1.3.2)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) due to unsanitized URIs in ng-srcset.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.3.0-rc.4 or higher.

[,1.3.0-rc.4)
  • L
Arbitrary Code Execution

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Arbitrary Code Execution. $parse allowed arbitrary code execution via Angular expressions under some very specific conditions. The only applications affected by these vulnerabilities are those that match all of the following conditions:

  • Application mixes server-side and client-side templating
  • The server-side templating contains XSS vulnerabilities
  • The vulnerabilities in the server-side templating are being guarded by server-side XSS filters or on the client-side via CSP
  • The server-side XSS vulnerabilities can be used to augment the client-side template processed by Angular Applications not meeting all of the conditions are not vulnerable.

How to fix Arbitrary Code Execution?

Upgrade org.webjars.npm:angular to version 1.3.0 or higher.

[,1.3.0)
  • H
Protection Bypass

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Protection Bypass via ng-attr-action and ng-attr-srcdoc allowing binding to Javascript. The fix was to require bindings to form[action] to be $sce.RESOURCE_URL and bindings to iframe[srcdoc] to be $sce.HTML

How to fix Protection Bypass?

Upgrade org.webjars.npm:angular to version 1.2.2 or higher.

[,1.2.2)
  • H
Arbitrary Script Injection

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Arbitrary Script Injection due to improper sanitization of the $event object passed to the native constructor functions. That isn't protected by the fast paths in $parse.

How to fix Arbitrary Script Injection?

Upgrade org.webjars.npm:angular to version 1.1.5 or higher.

[,1.1.5)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) Concatenating expressions makes it hard to reason about whether some combination of concatenated values are unsafe to use and could easily lead to XSS. By requiring that a single expression be used for *[src/ng-src] such as iframe[src], object[src], etc. (but not img[src/ng-src] since that value is sanitized), it is ensured that the value that's used is assigned or constructed by some JS code somewhere that is more testable or make it obvious that you bound the value to some user controlled value. This helps reduce the load when auditing for XSS issues.

To migrate your code, follow the example below:

Before:

JS:
scope.baseUrl = 'page';
scope.a = 1;
scope.b = 2;
HTML:
<!-- Are a and b properly escaped here? Is baseUrl
 controlled by user? -->
<iframe src="{{baseUrl}}?a={{a}&b={{b}}">

After:

JS:
var baseUrl = "page";
scope.getIframeSrc = function() {
  // There are obviously better ways to do this.  The
  // key point is that one will think about this and do
  // it the right way.
  var qs = ["a", "b"].map(function(value, name) {
  return encodeURIComponent(name) + "=" +
 encodeURIComponent(value);
}).join("&");
  // baseUrl isn't on scope so it isn't bound to a user
  // controlled value.
  return baseUrl + "?" + qs;
}
HTML: <iframe src="{{getIframeSrc()}}">Before:

##Details A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

ֿInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

Types of attacks

There are a few methods by which XSS can be manipulated:

Type Origin Description
Stored Server The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.
Reflected Server The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.
DOM-based Client The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.
Mutated The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.

Affected environments

The following environments are susceptible to an XSS attack:
  • Web servers
  • Application servers
  • Web application environments

How to prevent

This section describes the top best practices designed to specifically protect your code:
  • Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
  • Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
  • Give users the option to disable client-side scripts.
  • Redirect invalid requests.
  • Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
  • Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
  • Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.2.0 or higher.

[1.0.0,1.2.0)
  • M
Cross-site Scripting (XSS)

org.webjars.npm:angular is a WebJar for angular.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). DOM event handlers await events to occur (e.g. onclick, onkeypress, etc) and execute arbitrary Javascript code in accordance to the event. By default, interpolations inside DOM event handlers are disallowed. Using an interpolation for such handlers means that the interpolated value is a JS string being evaluated. Storing or generating such strings is error prone and likely leads to a Cross-site Scripting (XSS) vulnerability if you're not careful. On the other hand, ng-click and such event handlers evaluate Angular expressions that are a lot safer (e.g. No direct access to global objects - only scope), cleaner and harder to exploit.

To migrate the code follow the example below: Before:

JS:   scope.foo = 'alert(1)';
HTML: <div onclick="{{foo}}">

After:

JS:   scope.foo = function() { alert(1); }
HTML: <div ng-click="foo()">

How to fix Cross-site Scripting (XSS)?

Upgrade org.webjars.npm:angular to version 1.2.0 or higher.

[,1.2.0)