Buenas prácticas de seguridad de Angular

Anteriormente, compartimos nuestra guía Fundamentos de seguridad de AngularJS. Esta vez, vamos directo a las buenas prácticas de seguridad para Angular moderno. Puedes descargar aquí la guía de buenas prácticas de seguridad de Angular.

6 buenas prácticas de seguridad de Angular

1. La forma de trabajar de Angular te protege contra XSS

2. Usa innerHTML con precaución

3. Nunca uses plantillas generadas al concatenar entradas del usuario

4. Nunca uses API nativas del DOM para interactuar con elementos HTML

5. Evita los motores de plantillas en las plantillas del lado del servidor

6. Analiza tu proyecto de Angular para detectar componentes que introduzcan vulnerabilidades de seguridad

1. La forma de trabajar de Angular te protege contra XSS

Buena práctica de seguridad de Angular #1: usa la interpolación ({{  }}) para codificar de forma segura los caracteres potencialmente peligrosos y escapar expresiones HTML o CSS no confiables dentro de una expresión de plantilla. 

Angular, al igual que React y Vue.js, adopta un enfoque de seguridad predeterminada en la forma en que maneja la interpolación de cadenas en el navegador. De forma predeterminada, todos los datos se consideran inseguros y no confiables. Por eso, estas bibliotecas y otras bibliotecas de vista modernas siguen la buena práctica de codificar la salida de forma predeterminada para cualquier texto en un contexto HTML.

Como explicamos en detalle en nuestra publicación anterior sobre las buenas prácticas de seguridad de AngularJS, se recomienda seguir la forma de trabajar de Angular y usar la interpolación de cadenas integrada con llaves para escapar cualquier entrada maliciosa del usuario que pueda poner en riesgo tu aplicación web y exponerla potencialmente a vulnerabilidades de Cross-site Scripting (XSS).

2. Usa innerHTML con precaución

Buena práctica de seguridad de Angular #2: si debes agregar HTML dinámicamente a un componente, vincula su generación a [innerHTML]. Esto garantiza que los datos se interpreten como HTML en su contexto y se depuren, eliminando todas las etiquetas inseguras y evitando así que se ejecute código malicioso de cross-site scripting. Ten en cuenta que la acción de depurar no es lo mismo que codificar.

¿Cuál es la diferencia entre la depuración y la codificación de salida?

En la codificación de salida, las cadenas se reemplazan por su representación textual, que puede corresponder a una etiqueta HTML determinada. Por ejemplo, si se analiza una entrada como script, Angular puede mostrar ese texto codificando la notación de los corchetes angulares especiales, un estándar de muchas otras bibliotecas y frameworks que implementan buenas prácticas de seguridad. Para hacerlo, asigna lo que se conoce como entidades HTML mediante la codificación de entidades HTML y escribe en el DOM el siguiente texto: script. Luego, el navegador interpreta el contexto y muestra una etiqueta script.

A diferencia de la codificación de salida, la depuración o el filtrado adoptan un enfoque más proactivo: detectan los caracteres inseguros y los eliminan del texto que luego se escribe en el DOM.

Por lo tanto, el contexto es un factor decisivo para la codificación de salida y la depuración, ya que influye directamente en cómo realizar correctamente cada acción.

Podemos consultar la documentación de Angular para obtener más información sobre los contextos de seguridad. En sus propias palabras:

Angular define los siguientes contextos de seguridad:

* HTML se usa al interpretar un valor como HTML, por ejemplo, al vincularlo a innerHtml.* Style se usa al vincular CSS a la propiedad style.* URL se usa para propiedades de URL, como * Resource URL es una URL que se cargará y ejecutará como código, por ejemplo, en .

Ten en cuenta el tratamiento especial de las URL, que no se filtran.

3. Nunca uses plantillas generadas al concatenar entradas del usuario

Buena práctica de seguridad de Angular #3: nunca concatenes como cadena en una plantilla ninguna entrada que pueda provenir del usuario.

Debería haber muy pocos casos de uso —si es que hay alguno— que requieran concatenar plantillas en lugar de usar correctamente la interpolación de cadenas o la composición de componentes recomendada en una aplicación de Angular. Si encuentras esta mala práctica en una base de código, te recomendamos depurar o refactorizar la entrada proporcionada tanto como sea posible.

Este es un ejemplo de lo que debes tener en cuenta y evitar:

Buena práctica de seguridad de Angular: nunca uses plantillas generadas al concatenar entradas del usuario

Presta especial atención a la concatenación poco convencional de cadenas en plantillas de la línea 20. El valor de potentialUserInput puede ser una expresión maliciosa de origen desconocido o no confiable. Este es un ejemplo de una mala práctica que debes tener en cuenta.

A continuación, tienes una imagen más completa que puedes probar en mi entorno de pruebas de Angular y que muestra cómo la entrada del usuario no se maneja de forma segura si se concatena con la plantilla:

Buenas prácticas de seguridad de Angular en acción: nunca uses plantillas generadas al concatenar entradas del usuario

En este sentido, la recomendación oficial de la guía de seguridad de Angular dice:

“Nunca generes código fuente de plantillas concatenando entradas del usuario y plantillas. Para prevenir estas vulnerabilidades, usa el compilador de plantillas offline, también conocido como inyección de plantillas”.

- Guía de seguridad de Angular

Angular recomienda usar su compilador Ahead of Time para compilar las plantillas offline. Esto te ayuda a evitar por completo la gran cantidad de vulnerabilidades de inyección de plantillas:

ng build --aot
ng serve --aot

Ten en cuenta que, en las versiones más recientes de Angular —Angular v9 y posteriores—, la compilación Ahead of Time está activada de forma predeterminada al compilar con Ivy, lo que previene la inyección de plantillas:

{
  "projects": {
    "my-existing-project": {
      "architect": {
        "build": {
          "options": {
            ...
            "aot": true,
          }
        }
      }
    }
  }
}

4. Nunca uses API nativas del DOM para interactuar con elementos HTML

Buena práctica de seguridad de Angular #4: nunca uses API nativas del DOM para interactuar con elementos HTML de la página.

Evita la manipulación directa del DOM y, en su lugar, usa los mecanismos de plantillas de Angular y sus propias API para manipular el DOM. Como regla general, evita lo siguiente:

•  node.appendChild();

• usar los métodos del objeto document para interactuar con la página

• usar API de jQuery

Hay API nativas de Angular que permiten el mismo tipo de manipulación directa del DOM que recomendamos evitar; por ejemplo, la API ElementRef. Angular ElementRef presenta problemas de seguridad cuando se usa para acceder a un nodo directo del DOM y manipularlo.

Esta y otras interacciones fuera del conjunto de API de Angular podrían provocar vulnerabilidades de seguridad.

5. Evita los motores de plantillas en las plantillas del lado del servidor

Buena práctica de seguridad de Angular #5: evita los motores de plantillas de terceros para crear o agregar datos de plantillas en aplicaciones de Angular renderizadas del lado del servidor.

Si usaste Node.js para crear aplicaciones web, probablemente hayas usado en algún momento un motor de plantillas como EJS, Pug, Handlebars o alguna de sus alternativas. Se usan para administrar plantillas renderizadas del lado del servidor en la capa de vista y pueden incluir parciales, composiciones de diseño y otras funciones que ayudan a generar vistas dinámicamente.

Sin embargo, implementar estos mecanismos de motores de plantillas en una configuración de aplicación de Angular renderizada del lado del servidor podría provocar la inyección de código malicioso en una plantilla. Esto sucede porque los datos inyectados son externos al alcance de la API de Angular y no se pueden depurar, lo que supone los mismos riesgos que concatenar cadenas de plantillas.

6. Analiza tu proyecto de Angular para detectar componentes que introduzcan vulnerabilidades de seguridad

Buena práctica de seguridad de Angular #6: analiza siempre las dependencias de código abierto de tu proyecto de Angular y sus componentes para detectar vulnerabilidades de seguridad. Usa la plataforma o CLI de Snyk gratis para encontrar, corregir y monitorear vulnerabilidades de seguridad.

Al usar bibliotecas de terceros, como Angular y su ecosistema de módulos o componentes, debes tener en cuenta lo siguiente: las vulnerabilidades de seguridad que afectan a la biblioteca principal de Angular y las vulnerabilidades de seguridad en los módulos de Angular de terceros que importas y usas en tu proyecto.

Usar componentes con vulnerabilidades conocidas es un riesgo de seguridad web documentado en OWASP Top 10 que debes conocer. De hecho, la imagen a continuación muestra una lista de módulos de Angular con vulnerabilidades de seguridad conocidas, por ejemplo, las que se señalarían al ejecutar npm install o npm audit. Como puedes ver en esta imagen de nuestro informe de seguridad de frameworks de JavaScript, algunos reciben millones de descargas al año y, aun así, hasta la fecha no tienen una corrección de seguridad:

Seguridad de Angular: el riesgo de las dependencias indirectas

Cómo proteger aplicaciones web de Angular

Si usas npm audit, ya diste un excelente primer paso. ¡Vas por buen camino!

Sin embargo, aunque uses la función de auditoría de npm, todavía hay problemas de seguridad que debes mitigar:

• Quizá ya hayas corregido todas las vulnerabilidades de seguridad del proyecto, pero ¿qué pasa cuando se descubre una nueva vulnerabilidad en uno de esos módulos de Angular? ¿Sabrás si afecta a alguna de tus aplicaciones de Angular implementadas en Vercel, Netlify u otras plataformas?

• La otra preocupación es que npm audit solo rastrea vulnerabilidades conocidas que tienen un CVE oficial. En cambio, [Snyk rastrea más de 23 vulnerabilidades de seguridad en módulos relacionados con Angular](https://snyk.io/blog/angular-vs-react-security-bakeoff-2019/), que npm audit no reporta.

Snyk resuelve ambos problemas por ti y es gratis ;-)

¿Cómo empezar?

Crea tu cuenta gratuita de Snyk y conecta tus proyectos de frontend de GitHub o Bitbucket para que Snyk encuentre y cree automáticamente pull request para corregir los problemas.

Otra forma rápida de empezar y encontrar problemas de seguridad en Angular es usar la CLI de Snyk:

npm install -g snyk
snyk test

La CLI de Snyk proporciona más que solo vulnerabilidades CVE conocidas, a diferencia de npm audit, que no informa sobre estas.

Fuente: Angular vs. React: competencia de seguridad de 2019

Snyk ofrece recomendaciones prácticas para actualizar a una versión corregida.

Si buscas algo parecido a un escáner de seguridad para Angular, prueba Snyk para rastrear tus dependencias de código abierto, recibir notificaciones y corregirlas cuando se descubran vulnerabilidades.

Lecturas recomendadas:

• Si mantienes AngularJS o trabajas activamente en su desarrollo, te serán útiles las 10 buenas prácticas fundamentales de seguridad de AngularJS.

• ¿Cómo se compara la postura de seguridad de Angular con la de React? Publicamos un informe detallado sobre la seguridad de los frameworks de JavaScript.

¿Angular es seguro?

El nuevo framework Angular (Angular 2 y versiones posteriores) se considera seguro de forma predeterminada y no presenta vulnerabilidades de seguridad conocidas. En comparación, su predecesor, AngularJS, tiene más de 25 vulnerabilidades de seguridad conocidas públicamente, algunas tan recientes como de junio de 2020. Asegúrate de seguir las buenas prácticas de seguridad de Angular y consulta el informe de seguridad de frameworks de JavaScript de Snyk para conocer en profundidad la seguridad del ecosistema de módulos npm para Angular, React y otros proyectos.

¿Cómo proteger una aplicación de Angular?

Estas son algunas pautas fundamentales para garantizar la seguridad de una aplicación de Angular:

1. Como desarrollador, asegúrate de seguir la forma de trabajar de Angular y sus buenas prácticas para protegerte contra XSS. Por ejemplo, no debes usar innerHTML, ni plantillas generadas al concatenar entradas del usuario, ni API nativas del DOM para interactuar con elementos HTML.

2. Asegúrate de analizar tu proyecto de Angular para detectar componentes que introduzcan vulnerabilidades de seguridad. Aunque sigas las prácticas de seguridad propias de Angular, otros autores de módulos podrían no hacerlo y exponerte a problemas graves. No te limites a analizar: corrige y monitorea posibles problemas nuevos. Snyk es una excelente opción para eso y una herramienta gratuita que puedes conectar fácilmente a tus proyectos. Lee más sobre las buenas prácticas de seguridad de Angular.

¿Qué es más seguro, Angular o React?

El proyecto Angular (Angular 2+) no tiene vulnerabilidades de seguridad conocidas públicamente. React tiene 2 vulnerabilidades de seguridad que lo afectan, pero son de 2017 y probablemente ya estés usando una versión más reciente. Su predecesor, AngularJS, tiene más de 25 vulnerabilidades de seguridad. Si todavía lo desarrollas o mantienes, asegúrate de analizar tus proyectos con una herramienta de seguridad gratuita y diseñada para desarrolladores, como Snyk. Sobre este tema, puedes leer el informe sobre la seguridad de los frameworks de JavaScript, que analiza el estado de la seguridad en los ecosistemas de Angular y React.

¿Angular sanitiza las entradas?

De forma predeterminada, Angular codifica la salida de cualquier texto potencialmente peligroso que pueda provocar XSS, siempre que sigas las prácticas de codificación segura recomendadas por Angular, como usar las llaves dobles ({{}}) para una interpolación segura. Sin embargo, si usas el enlace innerHTML de Angular, Angular hará todo lo posible por protegerte y sanitizará el contenido peligroso. Aun así, esta debería ser tu última opción para agregar entradas de usuario.