Principes fondamentaux de la sécurité d’AngularJS

Dans cette fiche de bonnes pratiques de sécurité pour AngularJS, nous nous intéressons à AngularJS et présentons des conseils et des recommandations pour écrire du code sécurisé. En bref, cette fiche rassemble les principes fondamentaux de la sécurité d’AngularJS à destination des développeurs web.

Télécharger les principes fondamentaux de la sécurité d’AngularJS

Voici les 10 bonnes pratiques fondamentales en matière de sécurité d’AngularJS abordées dans cet article :

1. La « méthode Angular » vous protège contre les attaques XSS

2. Évitez les injections de données dans le DOM d’Angular

3. Évitez de charger dynamiquement des modèles Angular depuis des sources non fiables

4. Vulnérabilités de redirection ouverte dans AngularJS

5. Injection de code Angular côté serveur

6. Évitez d’utiliser l’API compatible avec jQuery .element d’Angular pour manipuler le DOM

7. Utilisez des linters de sécurité pour Angular

8. Analysez et corrigez les vulnérabilités des composants tiers d’Angular

9. Prise en charge intégrée du CSRF dans les applications Angular

10. Compatibilité intégrée d’Angular avec CSP

Pourquoi est-il si important de parler des bonnes pratiques de sécurité pour AngularJS ?

Selon notre précédente étude sur la sécurité des frameworks JavaScript, Angular v1.x représente environ 30 % de tous les téléchargements de versions d’Angular, soit un peu plus de 2 millions de téléchargements en juillet 2019.

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

Angular est-il meilleur qu’AngularJS ?

Angular est la version qui succède à AngularJS. Il convient de noter que nous n’avons trouvé aucune vulnérabilité de sécurité signalée dans l’ensemble des composants principaux d’Angular. En revanche, 23 vulnérabilités d’AngularJS sont répertoriées dans toutes les branches de publication de la version 1.x.

Quelle version d’AngularJS dois-je utiliser ?

Optez toujours pour la dernière version d’AngularJS — AngularJS 1.7 au moment de la rédaction de cet article —, qui est à jour en matière de correctifs de sécurité et sera prise en charge jusqu’au 30 juin 2021.

Un grand merci à Lewis Arden, qui a partagé des recherches approfondies et de précieuses informations sur la sécurité d’AngularJS. Voici son intervention sur la sécurisation d’AngularJS à OWASP London.

Vérifiez si votre projet AngularJS sur GitHub / Bitbucket présente des vulnérabilités de sécurité

1. La « méthode Angular » vous protège contre les attaques XSS

Par défaut, AngularJS applique un encodage automatique de la sortie et une assainisation des entrées adaptés au contexte pour toutes les valeurs de données insérées dans le DOM. Tant que vous suivez la « méthode Angular », vous bénéficiez de cette protection.

Examinons quelques exemples.

Utiliser ng-bind dans Angular

La directive ng-bind d’Angular vous permet de lier la valeur d’un élément HTML à celle définie dans le code Angular, par exemple dans le contrôleur.

Le fichier view.html suivant contient le modèle Angular qui utilise ng-bind pour interpoler une expression du code Angular et afficher sa valeur dans l’élément HTML div :

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

Le contrôleur qui fournit la valeur à cette vue est AboutController :

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

Comme vous pouvez le voir, la valeur de signature simule une tentative d’injection d’éléments HTML déclenchant une alerte du navigateur. Toutefois, lors de l’affichage, Angular encode des caractères tels que < en entités HTML. Le contenu s’affiche donc sous forme de texte au lieu d’être inséré dans le DOM comme un véritable élément HTML.

Utiliser les accolades d’Angular

Une autre façon de lier une valeur de données à des éléments HTML consiste à utiliser la convention des doubles accolades d’Angular. La directive ngBind et la notation avec accolades ont la même fonction, avec quelques différences subtiles en matière d’expérience utilisateur.

Voici un exemple de la façon dont Angular encode des données malveillantes avec les accolades. Commençons par ajouter une valeur de description à la vue :

<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>

Et voici le contrôleur correspondant, qui fournit une valeur destinée à injecter des attaques par script intersites dans la page :

(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";
 });
})();

Puisque cela suit la méthode Angular, vous pouvez voir comment Angular applique sa contre-mesure d’encodage de sortie contre les attaques par script intersites lorsque les accolades et les directives ngBind sont utilisées avec des entrées utilisateur potentiellement malveillantes :

À retenir :Profitez des protections par défaut d’Angular pour atténuer les vulnérabilités de script intersite (XSS) : interpolez les données selon la « méthode Angular » avec les directives ngBind ou des accolades, par exemple {{ data }}, afin qu’Angular applique par défaut l’encodage de sortie et l’assainisation.

2. Évitez les injections de données dans le DOM d’Angular

Détournement de la liaison HTML non sécurisée d’Angular

Les premières versions d’AngularJS, comme la version 1.2 et les versions antérieures, comportaient une directive ng-bind-html-unsafe qui permettait d’insérer des données HTML dans le DOM et de créer de nouveaux éléments. Cette directive était notamment utilisée pour créer des éléments DOM directement à partir de données saisies, puis filtrer certaines chaînes, par exemple en supprimant les liens.

Cette approche de liste noire des données est source d’erreurs et n’est pas toujours sûre, car de nouveaux vecteurs et de nouvelles méthodes d’attaque sont découverts au fil du temps, ce qui oblige à maintenir cette liste noire.

Voyons un exemple d’injection d’éléments HTML dans le DOM avec ng-bind-html-unsafe.

Un modèle Angular :

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

Et le contrôleur Angular associé à la vue :

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

La vue HTML générée contient « Contactez-moi » sous forme de véritable lien, qui déclenche une alerte lorsqu’on clique dessus :

Détournement du Strict Contextual Escaping d’Angular

La version 1.2 d’AngularJS a rendu obsolète la directive ng-bind-html-unsafe et introduit à la place le Strict Contextual Escaping (SCE). Le SCE permet d’échapper et d’assainir les données en fonction du contexte, mais pas des données d’un élément HTML spécifique.

Il existe toutefois des mécanismes de contournement qui permettent d’ignorer l’encodage et de considérer les données fournies comme sûres. Les méthodes Angular $sce.trustAsHtml() et $sce.trustAs(type, value) rendent ces actions possibles.

En outre, vous pouvez utiliser $sceProvider.enabled(false) pour désactiver globalement l’échappement contextuel strict et ignorer toute assainisation, en considérant les entrées comme fiables. C’est une autre mauvaise pratique à éviter. Nous vous conseillons de ne le faire que si vous avez de très bonnes raisons et de prévoir d’autres contre-mesures et protections.

Prenons l’exemple suivant : il vise à permettre aux utilisateurs de créer des liens, mais introduit des vulnérabilités de script intersite. Voici le modèle Angular correspondant :

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

Le contrôleur Angular est le suivant :

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>`
});

En créant un filtre Angular stripDangerousHTML, un développeur s’assure qu’aucun code JavaScript malveillant ne se retrouve dans l’attribut href et que seules des adresses e-mail sont autorisées après assainisation.

Si la valeur saisie par l’utilisateur dans emailAddress est 'javascript:alert(1)', la correspondance basée sur une expression régulière fonctionne parfaitement. En revanche, avec une valeur utilisateur telle que jav ascript:al ert(1);, elle ne fonctionne pas aussi bien. Cette entrée précise contourne la correspondance et produit une instruction JavaScript valide, entraînant une attaque XSS.

À retenir :Évitez les injections de données dans le DOM d’Angular, qui peuvent introduire des vulnérabilités.

• Dans Angular 1.2 et les versions antérieures, évitez d’utiliser la directive ng-bind-html-unsafe.

• Dans Angular 1.2 et les versions ultérieures, évitez de faire aveuglément confiance aux entrées utilisateur avec les méthodes Strict Contextual Escaping, telles que $sce.trustAsHtml(value).

3. Évitez de charger dynamiquement des modèles Angular depuis des sources non fiables

Le code Angular utilise constamment des modèles Angular. Ces modèles HTML ressemblent à ceci :

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

La plupart du temps, vous composez les modèles Angular à partir de fichiers associés à une application Angular lors de sa compilation. Il est toutefois aussi possible de charger ces modèles HTML à la demande côté client, lors de l’exécution, en envoyant une requête pour télécharger le modèle et l’évaluer dynamiquement.

Cela présente néanmoins le risque de charger des modèles de manière non sécurisée depuis des domaines non fiables, échappant au contrôle et aux garanties de confiance de l’application web. Les développeurs doivent également veiller à accéder aux modèles via des protocoles sécurisés, comme des versions récentes de TLS, afin d’atténuer les attaques de l’homme du milieu.

Voici un exemple de chargement dynamique d’un modèle Angular sur le réseau :

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

Angular permet de contrôler les ressources des modèles. La documentation officielle le décrit bien :

$sceDelegateProvider permet de consulter et de définir les listes blanches et noires utilisées pour vérifier que les URL servant à charger les modèles AngularJS et les autres URL exécutant des scripts sont sûres (tous les emplacements qui utilisent le contexte $sce.RESOURCE_URL)

Si le code de votre application Angular utilise le fournisseur de délégation SCE, veillez à configurer correctement la liste blanche des ressources :

• utilisez HTTPS comme protocole sécurisé pour récupérer les modèles distants et assurez-vous que le point de terminaison distant dispose d’une configuration TLS à jour.

• évitez d’utiliser le caractère générique à deux astérisques **pour les domaines ou les protocoles.

• si nécessaire, créez une liste noire pour renforcer la défense en profondeur.

4. Vulnérabilités de redirection ouverte dans AngularJS

Les API natives du navigateur permettent de naviguer entre les pages, notamment avec $window.location. Angular abstrait la gestion de la navigation grâce au service $location et fournit des méthodes telles que $location.url(), $location.path() et $location.hash(), entre autres, pour accéder à l’URL de navigation actuelle et la synchroniser au besoin.

Votre code Angular effectue peut-être la navigation en fonction des paramètres de requête de l’URL ou d’autres données liées à l’URL.

Prenons l’exemple suivant :

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

     window.location.href = referer
});

Ce code Angular a pour but d’analyser une URL, par exemple https://www.example.com/path/to/this#referer, puis de l’utiliser comme base pour naviguer vers une autre page.

Toutefois, puisque l’adresse URL est contrôlée par l’utilisateur qui consulte l’application web, celui-ci peut définir le fragment comme du code JavaScript valide — par exemple https://www.example.com/path/to/this#javascript:alert(1) — et exécuter cette URL.

De même, définir window.location.href à partir d’une entrée utilisateur — par exemple l’injection JavaScript dans le fragment — produirait le même résultat.

Principes fondamentaux de la sécurité d’AngularJS

Bonnes pratiques pour éviter les redirections ouvertes et l’injection de code JavaScript :

1. évitez la navigation entre les pages à partir d’entrées utilisateur absolues.

2. si vous devez effectuer une navigation en fonction d’une entrée utilisateur, utilisez des tables de correspondance pour associer cette entrée à une page ou à une URL.

3. ne concaténez jamais d’entrée utilisateur aux URL de navigation.

À retenir :Évitez les pièges des redirections ouvertes en utilisant directement les entrées utilisateur pour effectuer la navigation.

• Évitez les modèles tels que window.location.href = $location.hash, qui peuvent entraîner des attaques par injection de code JavaScript.

• Utilisez des tables de correspondance pour effectuer la navigation en fonction des entrées utilisateur.

5. Injection de code Angular côté serveur

Le code côté serveur assainit ou encode les entités HTML malveillantes, comme les scripts, mais il ne connaît pas le contexte AngularJS côté client. Les attaquants peuvent donc fournir une expression de modèle Angular — par exemple des accolades accompagnées d’une charge utile JavaScript — qui sera évaluée à l’exécution côté client et provoquera une attaque par injection.

Bonnes pratiques pour atténuer les injections de code Angular côté serveur :

• Évitez de mélanger les modèles côté serveur et côté client. Utilisez plutôt les modèles dans un seul contexte applicatif : côté serveur ou côté client.

• Limitez la portée de la directive ng-app : au lieu de l’appliquer au corps du document HTML, appliquez-la à un élément DOM spécifique de la page.

• Liez les données du modèle avec ng-bind ou ng-bind-html pour vous assurer que les entrées utilisateur sont correctement traitées grâce aux contrôles d’encodage de sortie et d’assainisation intégrés à ces directives Angular.

• Utilisez ng-non-bindable pour vous assurer qu’Angular ne traite pas les données comme une expression à évaluer et ainsi atténuer les injections de code Angular.

À retenir :Atténuez les injections de code Angular côté serveur.

6. Évitez d’utiliser l’API .element d’Angular, compatible avec jQuery, pour manipuler le DOM

Angular fournit une API angular.element() offrant une compatibilité avec les API de type jQuery (jqLite) pour interroger et manipuler directement le DOM.

Cela peut sembler être un moyen pratique d’accéder au DOM et d’interagir avec lui. Toutefois, cette méthode introduit des risques d’injection en raison de l’injection non sécurisée dans le DOM.

Voici un modèle Angular simple :

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

Voici le contrôleur Angular associé, qui utilise angular.element() pour manipuler la page :

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

Le problème vient ici de element.after(), qui ajoute le contenu de $scope.content au DOM sans encodage ni assainissement, puisque son fonctionnement est compatible avec l’API after de jQuery. Si la valeur de cette variable contient du code malveillant, les protections d’Angular ne s’appliquent pas et vous vous exposez à une attaque potentielle par XSS.

Pour en savoir plus sur angular.element, consultez la documentation officielle d’Angular : https://docs.angularjs.org/api/ng/function/angular.element.

À retenir : évitez d’utiliser l’API angular.element() d’Angular, compatible avec jQuery, pour manipuler le DOM. La création directe d’éléments HTML dans le DOM peut entraîner des vulnérabilités de type cross-site scripting.

7. Utilisez des linters de sécurité pour Angular

Les linters sont courants dans le développement JavaScript, et les développeurs utilisent souvent des projets populaires comme ESLint avec des plugins qui étendent ses fonctionnalités. Le projet eslint-plugin-angular aide à respecter les conventions et recommandations générales de programmation Angular. Il comprend également des règles de sécurité, dont no-jquery-angularelementquiinterdit d’encapsuler des objets angular.element avec jQuery ou $.

Voici un exemple de détection de problèmes par le plugin ESLint, selon la documentation officielle :

/*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 vous ne comprenez pas pourquoi l’utilisation de angular.element() pose un problème de sécurité, nous vous recommandons de lire la section précédente : Évitez d’utiliser l’API .element d’Angular, compatible avec jQuery, pour manipuler le DOM.

À retenir : utilisez des outils d’analyse statique du code pour repérer automatiquement les pratiques non sécurisées et alerter les développeurs dès qu’elles sont détectées, au début du processus de développement. Les linters de sécurité font partie des bonnes pratiques fondamentales de sécurité AngularJS :

• eslint-plugin-scanjs-rules

• eslint-plugin-angular interdit l’utilisation de angular.element() par Angular

8. Analysez et corrigez les vulnérabilités des composants Angular tiers

Il est fort probable que vous utilisiez des packages open source en complément du cœur d’Angular et de ses composants étendus pour créer votre application web. En fait, le projet AngularJS lui-même comporte des vulnérabilités. Selon une étude de Snyk sur la sécurité des frameworks JavaScript, la branche AngularJS 1.x présente plus de 20 vulnérabilités.

De plus, les dépendances utilisées pour créer votre application web basée sur Angular peuvent également présenter des vulnérabilités. Comme le montre le tableau ci-dessous, certaines de ces vulnérabilités ne disposent toujours d’aucun correctif.

Rechercher les vulnérabilités

Vous cherchez un outil d’analyse de sécurité pour AngularJS ? Testez la sécurité d’AngularJS et tenez-vous au courant des vulnérabilités de votre projet frontend avec Snyk en connectant vos projets GitHub ou Bitbucket. Snyk détecte automatiquement les problèmes et crée des pull requests pour les corriger.

Pour commencer rapidement et détecter les problèmes de sécurité AngularJS, vous pouvez aussi utiliser l’interface de ligne de commande Snyk :

npm install -g snyk
snyk test

Lorsque vous lancez un test Snyk, Snyk signale les vulnérabilités détectées et affiche les chemins vulnérables pour vous permettre de suivre l’arborescence des dépendances et de comprendre quel module a introduit une vulnérabilité.

Malheureusement, si vous utilisez npm audit, vous êtes probablement passé à côté de toutes les vulnérabilités AngularJS signalées par Snyk. npm audit passe également à côté des trois vulnérabilités de React, donnant aux développeurs un faux sentiment de sécurité.

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

Snyk vous propose des conseils concrets pour remédier aux problèmes, notamment en mettant à niveau vers une version corrigée au moyen d’une pull request automatisée créée par Snyk dans votre dépôt. Si aucun correctif n’est disponible, vous pouvez également appliquer un patch fourni par Snyk pour atténuer la vulnérabilité.

Si vous cherchez un outil comparable à un scanner de sécurité AngularJS, commencez par Snyk pour suivre vos dépendances open source, recevoir des alertes et corriger les vulnérabilités dès leur détection.

À retenir : à ce jour, AngularJS présente plus de 20 vulnérabilités et certains composants Angular, téléchargés des millions de fois, restent vulnérables.

• Connectez Snyk à GitHub ou à d’autres SCM pour intégrer au mieux vos projets à votre CI/CD.

• Snyk détecte les vulnérabilités des composants tiers que vous utilisez et crée des pull requests de correction. Vous pouvez ainsi fusionner la mise à jour de version et atténuer le risque.

9. Prise en charge intégrée de CSRF pour les applications Angular

La falsification de requête intersites (CSRF, XSRF) est une attaque de sécurité web qui consiste à inciter les utilisateurs à effectuer des actions qu’ils n’avaient pas l’intention d’effectuer, comme envoyer une requête API qui soumet un formulaire.

Pour atténuer les vulnérabilités CSRF, on peut utiliser des jetons générés aléatoirement ou, mieux encore, des nonces cryptographiques afin de vérifier qu’une requête est fiable.

Angular prend en charge nativement les jetons CSRF : il lit les cookies respectant certaines conventions de nommage, comme XSRF-TOKEN, envoyés par le serveur, puis ajoute leur valeur aux requêtes HTTP suivantes émises par l’application Angular.

La gestion complète des jetons CSRF est assurée par le service $http d’AngularJS. Dans les versions plus récentes d’Angular, elle est également disponible via HttpClient, dans le module officiellement pris en charge @angular/common/http. D’autres options permettent de configurer le nom du cookie utilisé pour le jeton CSRF et le comportement général, via l’API $http.xsrfCookieName, entre autres.

À retenir : Angular prend en charge nativement la gestion des jetons CSRF côté client via son service $http. Utilisez ce service plutôt que de développer votre propre solution.

10. Compatibilité intégrée d’Angular avec CSP

Certaines fonctionnalités d’Angular sont incompatibles avec des restrictions CSP courantes, comme celles qui interdisent l’évaluation de code JavaScript intégré. Cependant, plutôt que de désactiver complètement CSP, ce qui est déconseillé, Angular propose la directive ngCsp, compatible avec la configuration CSP.

La politique de sécurité du contenu (CSP) est une norme web qui permet de définir des politiques de confiance. Elle sert principalement de couche de défense supplémentaire pour renforcer la sécurité et contribue à atténuer des problèmes comme les injections XSS.

AngularJS intègre des mécanismes de contrôle liés à CSP. Toutefois, lorsqu’ils sont activés, certaines fonctionnalités doivent être exclues — par exemple, les scripts et expressions intégrés sont interdits, car eval() n’est pas autorisé. Or, AngularJS en a besoin en interne pour certaines fonctionnalités.

Pour en savoir plus sur CSP, consultez les ressources recommandées sur le site de Mozilla ainsi que la documentation de l’API Angular sur la directive ngCsp.

À retenir : la mise en place d’une politique de sécurité du contenu (CSP) est une étape importante pour ajouter une couche de sécurité, notamment pour atténuer les attaques de type cross-site scripting.

10 bonnes pratiques fondamentales pour la sécurité AngularJS :

1. Les protections intégrées à Angular contre les attaques XSS

2. Évitez les injections dans les entrées liées au DOM d’Angular

3. Évitez de charger dynamiquement des modèles Angular depuis des sources non fiables

4. Les vulnérabilités de redirection ouverte dans AngularJS

5. L’injection de code Angular côté serveur

6. Évitez d’utiliser l’API .element d’Angular, compatible avec jQuery, pour manipuler le DOM

7. Utilisez des linters de sécurité pour Angular

8. Analysez et corrigez les vulnérabilités des composants Angular tiers

9. Prise en charge intégrée de CSRF pour les applications Angular

10. Compatibilité intégrée d’Angular avec CSP

Téléchargez la fiche-conseil sur les bonnes pratiques de sécurité AngularJS !