Fundamentos de seguridad de AngularJS

En esta guía de buenas prácticas de seguridad de AngularJS, nos centramos en AngularJS y presentamos consejos y pautas para garantizar prácticas de programación seguras. En esencia, esta guía reúne los fundamentos de seguridad de AngularJS para desarrolladores web.

Descargar Fundamentos de seguridad de AngularJS

A continuación, presentamos las 10 buenas prácticas fundamentales de seguridad de AngularJS que abordamos en esta publicación del blog:

1. El «estilo Angular» te protege de XSS

2. Evita la inyección de entradas relacionadas con el DOM de Angular

3. Evita cargar dinámicamente plantillas de Angular desde fuentes no confiables

4. Vulnerabilidades de redirección abierta en AngularJS

5. Inyección de código Angular del lado del servidor

6. Evita usar la API compatible con jQuery de Angular .element para manipular el DOM

7. Usa linters de seguridad para Angular

8. Analiza y corrige vulnerabilidades en componentes de terceros de Angular

9. Compatibilidad integrada con CSRF para aplicaciones Angular

10. Compatibilidad integrada de Angular con CSP

¿Por qué es tan importante hablar sobre las buenas prácticas de seguridad de AngularJS?

Según nuestro estudio anterior sobre la seguridad de los frameworks de JavaScript, Angular v1.x representa aproximadamente el 30 % de todas las descargas de versiones de Angular y poco más de 2 millones de descargas en julio de 2019.

fuente: https://snyk.io/blog/javascript-frameworks-security-report-2019/

¿Angular es mejor que AngularJS?

Angular es la versión sucesora de AngularJS. Cabe destacar que no encontramos vulnerabilidades de seguridad reportadas en el conjunto principal de componentes de Angular. Sin embargo, hay 23 vulnerabilidades de AngularJS registradas en todas las ramas de lanzamiento de la versión 1.x.

¿Qué versión de AngularJS debería usar?

Siempre deberías optar por la versión más reciente de AngularJS —AngularJS 1.7, al momento de escribir esto—, que siempre está actualizada con las correcciones de seguridad y tendrá soporte hasta el 30 de junio de 2021.

Muchas gracias a Lewis Arden, quien anteriormente compartió una investigación exhaustiva e información útil sobre la seguridad de AngularJS. Aquí puedes ver su charla sobre cómo proteger AngularJS en OWASP London.

Analiza tu proyecto de AngularJS en GitHub/Bitbucket para detectar vulnerabilidades de seguridad

1. El «estilo Angular» te protege de XSS

De forma predeterminada, AngularJS aplica codificación automática de salida y sanitización de entradas según el contexto para todos los valores de datos que se insertan en el DOM. Siempre que sigas el «estilo Angular», te beneficiarás de esta protección.

Veamos algunos ejemplos.

Usar ng-bind de Angular

La directiva ng-bind de Angular te permite vincular el valor de un elemento HTML con un valor definido en el código de Angular, por ejemplo, en el controlador.

El siguiente view.html contiene la plantilla de Angular que usa ng-bind para interpolar una expresión del código de Angular y mostrar su valor en el elemento HTML div:

<div class="jumbotron" ng-controller="AboutController as about">
 <h1>About</h1>
 <p>
   Signed by:
 </p>
 <div ng-bind="about.signature"></div>
</div>

El controlador que proporciona el valor para esta vista es AboutController:

(function() {
 "use strict";
 angular.module("angularjs-starter").controller("AboutController", function() {
   this.signature =
     'Yours truly, Angle <img src="x" onError="alert('its me!')"/>> Bob';
 });
})();

Como puedes ver, el valor de la firma simula un intento de inyectar elementos HTML que activan una alerta del navegador. Sin embargo, al mostrarse en pantalla, Angular codifica caracteres como < en sus entidades HTML. Por eso se muestran como texto, en lugar de insertarse en el DOM como elementos HTML reales.

Usar las llaves de Angular

Otra forma de vincular un valor de datos con los valores de elementos HTML es usar la convención de Angular de las llaves dobles. La directiva ngBind y la notación con llaves son equivalentes, con algunas diferencias sutiles en la experiencia de usuario.

Este es un ejemplo de cómo Angular codifica datos maliciosos al usar llaves, comenzando por agregar un valor de descripción a la vista:

<div class="jumbotron" ng-controller="AboutController as about">
 <h1>About</h1>
 <p>
   {{ about.description }}
 </p>

 <p>
   Signed by:
 </p>
 <div ng-bind="about.signature"></div>
</div>

Y el controlador correspondiente que proporciona un valor con la intención maliciosa de inyectar ataques de Cross-site Scripting en la página:

(function() {
 "use strict";
 angular.module("angularjs-starter").controller("AboutController", function() {
   this.signature =
     'Yours truly, Angle <img src="x" onError="alert('its me!')"/>> Bob';
   this.description =
     "hello there you <a href="javascript:alert('hello')">crazy</a> diamond";
 });
})();

Como se hace según el estilo Angular, puedes ver cómo Angular aplica su contramedida de codificación de salida frente a ataques de Cross-site Scripting cuando se usan las llaves y las directivas ngBind con entradas potencialmente maliciosas de los usuarios:

Conclusión clave:Aprovecha las protecciones predeterminadas de Angular para mitigar las vulnerabilidades de Cross-site Scripting (XSS): interpola los datos según el «estilo Angular» con las directivas ngBind o con llaves, como {{ data }}, para que Angular aplique la codificación de salida y la sanitización de forma predeterminada.

2. Evita la inyección de entradas relacionadas con el DOM de Angular

Abuso de la vinculación de HTML no seguro de Angular

Las versiones anteriores de AngularJS, como la 1.2 y las anteriores, tenían una directiva ng-bind-html-unsafe que permitía insertar datos HTML en el DOM y crear elementos nuevos. Una práctica consistía en crear elementos DOM directamente a partir de datos de entrada y luego filtrar ciertas cadenas, por ejemplo, eliminar enlaces y otros elementos.

Este método de crear listas negras de datos es propenso a errores y no siempre es seguro, ya que con el tiempo se descubren nuevos vectores y métodos de ataque, y es necesario mantener esas listas.

Veamos un ejemplo de cómo ng-bind-html-unsafe inyecta elementos HTML en el DOM.

Una plantilla de Angular:

<div ng-controller="AboutController" ng-app>
  <span>{{email}}</span>
  <div ng-bind-html-unsafe="link">
  </div>
</div>

Y el controlador de Angular asociado a la vista:

function AboutController($scope) {
  $scope.email = 'Email me:'
  $scope.link = "<a href='javascript:alert(1)'>Contact me</a>"
}

La vista HTML renderizada incluirá «Contáctame» como un enlace real que activa una alerta al hacer clic:

Abuso de Strict Contextual Escaping de Angular

La versión 1.2 de AngularJS dejó obsoleta la directiva ng-bind-html-unsafe e introdujo en su lugar Strict Contextual Escaping (SCE). SCE permite escapar y sanitizar datos según el contexto, pero no según los datos de un elemento HTML específico.

Dicho esto, existen mecanismos para omitir la codificación y asumir que los datos proporcionados son seguros. Esto es posible con los métodos de Angular $sce.trustAsHtml() y $sce.trustAs(type, value).

Además, es posible usar $sceProvider.enabled(false)para desactivar globalmente el escape contextual estricto e ignorar toda sanitización, confiando en la entrada. Esta es otra mala práctica. Te recomendamos hacerlo solo si tienes razones realmente válidas y asegurarte de incluir otras contramedidas y defensas.

Veamos el siguiente ejemplo, que pretende permitir que los usuarios creen enlaces, pero a la vez introduce vulnerabilidades de Cross-site Scripting. La plantilla de Angular es:

<html>
  <body ng-app='myApp'>
    <div ng-controller="AboutController">
      <span>{{email}}</span>
      <div ng-bind-html="link | stripDangerousHTML">
      </div>
    </div>
  </body>
</html>

El controlador de Angular es:

var myApp = angular.module('myApp', []);

myApp.filter('stripDangerousHTML', function($sce) {
  return function(value) {
    let dataInput = value
    dataInput = dataInput
      .replace(/javascript/g, '')
      .replace(/alert/g, '');
    return $sce.trustAsHtml(dataInput);
  }
})

myApp.controller('AboutController', function($scope) {
  // this is filtered ok:
  // const emailAddress = 'javascript:alert(1)'
  // but is this??
  const emailAddress = `jav
ascript:al
ert(1);`
  $scope.email = 'Email me:'
  $scope.link = `Hi there, <a href="${emailAddress}">Contact me</a>`
});

Al crear un filtro de Angular stripDangerousHTML, el desarrollador se asegura de que no se incluya código JavaScript malicioso en el atributo href y de que solo se permitan correos electrónicos tras la sanitización.

Si la entrada proporcionada por el usuario para emailAddress es 'javascript:alert(1)', la coincidencia de patrones basada en expresiones regulares funciona bien. Sin embargo, si el valor de entrada proporcionado por el usuario es jav ascript:al ert(1);, no funciona tan bien. Esta entrada específica evita la coincidencia de patrones y produce una instrucción JavaScript válida que provoca una XSS.

Conclusión clave:Evita la inyección de entradas relacionadas con el DOM de Angular, ya que puede introducir vulnerabilidades.

• En Angular 1.2 y versiones anteriores, evita usar la directiva ng-bind-html-unsafe

• En Angular 1.2 y versiones posteriores, evita confiar ciegamente en entradas de usuario mediante métodos de Strict Contextual Escaping, como $sce.trustAsHtml(value)

3. Evita cargar dinámicamente plantillas de Angular desde fuentes no confiables

El código de Angular usa plantillas de Angular constantemente. Estas plantillas HTML tienen este aspecto:

<div>
  Hello, {{ name }}
</div>

La mayoría de las veces, las plantillas de Angular se componen de archivos que se vinculan a una aplicación Angular durante la compilación. Sin embargo, también es posible cargar estas plantillas HTML de forma diferida durante la ejecución desde el cliente, enviando una solicitud para descargarlas y evaluándolas dinámicamente.

Aun así, esto introduce el riesgo de cargar plantillas de forma insegura desde dominios no confiables que escapan al control y la confianza de la aplicación web. Además, los desarrolladores deben tener cuidado de acceder a las plantillas mediante protocolos seguros, como versiones actualizadas de TLS, para mitigar los ataques de intermediario.

Un ejemplo de cómo se carga dinámicamente una plantilla de Angular a través de la red:

angular.module(‘myModule’)
  .component(‘myComponent’, {
     templateUrl: ‘/path/to/template.html’,
     controller: function() {}
   });

Angular ofrece una forma de controlar los recursos de las plantillas. La documentación oficial lo describe claramente:

$sceDelegateProvider permite obtener y establecer las listas de permitidos y bloqueados que se usan para garantizar que las URL de origen de las plantillas de AngularJS y otras URL que ejecutan scripts sean seguras (todos los lugares que usan el contexto $sce.RESOURCE_URL)

Si el código de tu aplicación Angular usa el proveedor de delegación SCE, debes asegurarte de configurar correctamente la lista de recursos permitidos:

• usa HTTPS como medio seguro para obtener las plantillas remotas y asegúrate de que el endpoint remoto tenga una configuración de TLS actualizada.

• evita usar el comodín de doble asterisco ** para dominios o protocolos.

• cuando sea necesario, crea una lista de bloqueados para agregar una capa adicional de defensa.

4. Vulnerabilidades de redirección abierta en AngularJS

Las API nativas del navegador permiten navegar entre páginas, por ejemplo, con $window.location. Angular abstrae la gestión de navegación mediante el proveedor de servicios $location y ofrece métodos como $location.url(), $location.path() y $location.hash(), entre otros, para acceder a la URL de navegación actual y sincronizarla cuando sea necesario.

Es posible que tengas código de Angular que realice la navegación según los parámetros de consulta de la URL u otros datos relacionados con ella.

Considera el siguiente ejemplo:

myApp.controller('AboutController', function($scope, $location) {
    $scope.submit = function() {
       const referer = $location.hash()
     }

     window.location.href = referer
});

El propósito de este código de Angular es analizar una URL, por ejemplo, https://www.example.com/path/to/this#referer, y usarla como base para navegar a otra página.

Sin embargo, como el usuario que navega por la aplicación web controla la dirección URL, puede establecer el hash como código JavaScript válido —por ejemplo, https://www.example.com/path/to/this#javascript:alert(1)— y ejecutar esa URL.

Del mismo modo, establecer window.location.href con una entrada del usuario —por ejemplo, el caso de inyección de JavaScript en el hash— tendría el mismo resultado.

Fundamentos de seguridad de AngularJS

Buenas prácticas para evitar redirecciones abiertas e inyección de código JavaScript:

1. evita navegar entre páginas basándote en entradas absolutas del usuario.

2. si necesitas navegar entre páginas según entradas del usuario, usa mapas de diccionario para asociar esas entradas con una página o URL.

3. nunca concatenes entradas del usuario en las URL de navegación entre páginas.

Conclusión clave:Evita los problemas de redirección abierta al usar directamente las entradas proporcionadas por el usuario para navegar entre páginas.

• Evita patrones como window.location.href = $location.hash, que pueden provocar ataques de inyección de código JavaScript.

• Usa mapas de diccionario para navegar entre páginas según las entradas proporcionadas por el usuario.

5. Inyección de código Angular del lado del servidor

Aunque el código del lado del servidor sanitiza o codifica entidades HTML maliciosas, como scripts, no reconoce el contexto de AngularJS del lado del cliente. Por eso, los atacantes pueden proporcionar una expresión de plantilla de Angular, por ejemplo, llaves con una carga útil adicional de JavaScript, que luego se evalúa durante la ejecución en el cliente y genera un ataque de inyección.

Buenas prácticas para mitigar la inyección de código Angular del lado del servidor:

• Evita mezclar plantillas del lado del servidor y del cliente; en su lugar, usa plantillas dentro de un solo contexto de aplicación: el del servidor o el del cliente.

• Reduce el alcance de la directiva ng-app: en lugar de aplicarla al cuerpo del documento HTML, limítala a un elemento DOM específico de la página.

• Vincula los datos de la plantilla a ng-bind o ng-bind-html para garantizar que las entradas del usuario se procesen correctamente con la compatibilidad de estas directivas de Angular para la codificación de salida y los controles de sanitización.

• Usa ng-non-bindable para asegurarte de que Angular no trate los datos como una expresión que debe evaluarse y, así, mitigar la inyección de código Angular.

Conclusión clave:Mitiga la inyección de código Angular del lado del servidor.

6. Evita usar la API .element de Angular compatible con jQuery para manipular el DOM

Angular ofrece una API angular.element() compatible con jQuery (jqLite) para consultar y manipular el DOM directamente.

Puede parecer una forma práctica de acceder al DOM e interactuar con él; sin embargo, introduce posibles vulnerabilidades de inyección debido a la inserción insegura en el DOM.

Considera la siguiente plantilla sencilla de Angular:

    <div ng-controller="AboutController">
      <span id=”content”>{{content}}</span>
    </div>

A continuación se muestra el controlador de Angular asociado, que usa angular.element() para manipular la página:

function AboutController($scope) {
  const element = angular.element(‘#content’)
  element.after($scope.content)
}

El problema está en element.after(), que agrega el contenido de $scope.content al DOM sin codificarlo ni sanitizarlo, ya que es compatible con la API after de jQuery. Si el valor de esa variable incluye contenido malicioso, no se aplican las protecciones de Angular y quedas expuesto a posibles ataques de XSS.

Más información sobre angular.element en la documentación oficial de Angular: https://docs.angularjs.org/api/ng/function/angular.element.

Conclusión clave: Evita usar la API angular.element() de Angular, compatible con jQuery, para manipular el DOM, ya que esto puede causar vulnerabilidades de Cross-site Scripting por crear elementos HTML directamente en el DOM.

7. Usa linters de seguridad para Angular

Los linters son habituales en el desarrollo con JavaScript, y los desarrolladores suelen usar proyectos populares como ESLint junto con plugins que amplían sus funciones. El proyecto eslint-plugin-angular ayuda a seguir las convenciones y pautas generales de programación de Angular. También incluye algunas reglas de seguridad, una de las cuales es no-jquery-angularelementqueprohíbe envolver objetos angular.element con jQuery o $.

Este es un ejemplo de cómo el plugin de ESLint detecta problemas, según la documentación oficial:

/*eslint angular/no-jquery-angularelement: 2*/
// invalid
$(angular.element("#id")) // error: angular.element returns already a jQLite element. No need to wrap with the jQuery object

// invalid
jQuery(angular.element("#id")) // error: angular.element returns already a jQLite element. No need to wrap with the jQuery object

Si no tienes claro por qué usar angular.element() es un problema de seguridad, te recomendamos leer la sección anterior: Evita usar la API .element de Angular compatible con jQuery para manipular el DOM.

Conclusión clave:Usa herramientas de análisis estático de código para automatizar la detección de código inseguro y avisar a los desarrolladores cuando esto ocurra, en una etapa temprana del desarrollo. Estos linters de seguridad forman parte de los fundamentos de seguridad de AngularJS:

• eslint-plugin-scanjs-rules

• eslint-plugin-angular prohíbe el uso de angular.element() de Angular

8. Analiza y corrige las vulnerabilidades en componentes de terceros de Angular

Es muy probable que uses paquetes de código abierto además del núcleo de Angular y sus componentes extendidos para crear tu aplicación web. De hecho, el propio proyecto AngularJS tiene vulnerabilidades. Según un estudio de Snyk sobre la seguridad de los frameworks de JavaScript, AngularJS tiene más de 20 vulnerabilidades de seguridad en la rama de versiones Angular 1.x.

Además, las dependencias que usas para crear tu aplicación web basada en Angular también podrían tener vulnerabilidades de seguridad. Como muestra la siguiente tabla, algunas de esas vulnerabilidades todavía no tienen una solución disponible.

Analiza en busca de vulnerabilidades

¿Buscas un escáner de seguridad para AngularJS? Puedes realizar pruebas de seguridad en AngularJS y mantenerte al día sobre las vulnerabilidades de seguridad de tu proyecto de frontend con Snyk y conectando tus proyectos de GitHub o Bitbucket. Así, Snyk detecta automáticamente los problemas y crea pull request con correcciones.

Otra forma rápida de empezar y detectar problemas de seguridad en AngularJS es usar Snyk CLI:

npm install -g snyk
snyk test

Cuando ejecutas una prueba de Snyk, Snyk informa las vulnerabilidades detectadas y muestra las rutas vulnerables para que puedas rastrear el árbol de dependencias y entender qué módulo introdujo una vulnerabilidad.

Lamentablemente, si usas npm audit, es probable que no hayas detectado ninguna de las vulnerabilidades de seguridad de AngularJS que informa Snyk. npm audit tampoco detecta las tres vulnerabilidades de React, lo que da a los desarrolladores una falsa sensación de seguridad.

fuente: https://snyk.io/blog/angular-vs-react-security-bakeoff-2019/

Snyk te ofrece recomendaciones prácticas para actualizar a una versión corregida mediante un pull request automatizado que Snyk abre en tu repositorio. Si no hay una solución disponible, también puedes aplicar un parche que Snyk proporciona para mitigar la vulnerabilidad.

Si buscas algo parecido a un escáner de seguridad para AngularJS, empieza con Snyk para hacer seguimiento de tus dependencias de código abierto, recibir notificaciones y corregirlas cuando se detecten vulnerabilidades.

Conclusión clave:AngularJS tiene más de 20 vulnerabilidades hasta la fecha, y hay componentes de Angular con millones de descargas que todavía son vulnerables.

• Conecta Snyk con GitHub u otros SCM para lograr una integración óptima de CI/CD con tus proyectos.

• Snyk encuentra vulnerabilidades en los componentes de terceros que usas y abre pull request con correcciones para que puedas integrar la actualización de versión y mitigar el riesgo.

9. Compatibilidad integrada con CSRF en aplicaciones Angular

La falsificación de solicitudes entre sitios (CSRF, XSRF) es un ataque a la seguridad web en el que se engaña a los usuarios para que realicen acciones que no tenían intención de hacer, como enviar una solicitud a una API que envía un formulario.

Una técnica para mitigar las vulnerabilidades CSRF consiste en usar tokens generados aleatoriamente o, mejor aún, nonces criptográficos como medio para autenticar que una solicitud es confiable.

Angular tiene compatibilidad integrada con tokens CSRF: lee cookies con nombres específicos, como XSRF-TOKEN, que envía el servidor, y agrega su valor a las siguientes solicitudes HTTP que realiza la aplicación Angular.

La gestión completa de los tokens CSRF se realiza en el servicio $http de AngularJS. En las versiones más recientes de Angular también se ofrece a través de HttpClient, en el módulo @angular/common/http, que cuenta con soporte oficial. También permite configurar el nombre de la cookie para el token CSRF y el comportamiento general mediante la API $http.xsrfCookieName, entre otras.

Conclusión clave:Angular incluye compatibilidad integrada para gestionar tokens CSRF en el cliente mediante el servicio $http. Usa este servicio en lugar de crear tu propia solución.

10. Compatibilidad integrada de Angular con CSP

Algunas funciones de Angular entran en conflicto con restricciones comunes de CSP, como las que prohíben evaluar código JavaScript en línea. Sin embargo, en lugar de desactivar CSP por completo, algo que no se recomienda, Angular ofrece la directiva ngCsp, compatible con la configuración de CSP.

La política de seguridad de contenido (CSP) es un estándar web que permite establecer políticas de confianza. Se usa principalmente como una capa adicional de defensa para reforzar la seguridad y ayuda a mitigar problemas como la inyección (XSS).

AngularJS cuenta con controles integrados relacionados con CSP, pero al activarlos es necesario excluir algunas funciones, por ejemplo, impedir los scripts y las expresiones en línea, ya que no se permite eval(). Sin embargo, AngularJS lo necesita internamente para algunas de sus funciones.

Mozilla ofrece lecturas recomendadas sobre CSP en su sitio web, y Angular tiene documentación de la API para la directiva ngCsp.

Conclusión clave: Implementar una política de seguridad de contenido (CSP) es un paso importante para agregar una capa adicional de seguridad, especialmente una que ayude a mitigar los ataques de Cross-site Scripting.

10 prácticas recomendadas fundamentales de seguridad para AngularJS:

1. El «estilo Angular» te protege contra XSS

2. Evita la inyección de entradas relacionadas con el DOM de Angular

3. Evita cargar dinámicamente plantillas de Angular desde fuentes no confiables

4. Vulnerabilidades de redireccionamiento abierto en AngularJS

5. Inyección de código de Angular en el servidor

6. Evita usar la API .element de Angular compatible con jQuery para manipular el DOM

7. Usa linters de seguridad para Angular

8. Analiza y corrige las vulnerabilidades en componentes de terceros de Angular

9. Compatibilidad integrada con CSRF en aplicaciones Angular

10. Compatibilidad integrada de Angular con CSP

¡Descarga la guía de prácticas recomendadas de seguridad para AngularJS!