Considérations de sécurité

Lorsque vous ajoutez Persona sur votre site, il s'occupe du fardeau que représente la sécurité tant qu'il le peut. Cependant, certains aspects de la sécurité peuvent uniquement être gérés par votre site. Ils sont listés ci-dessous.

Pratiques essentielles

Vérifier les assertions côté serveur

Lorsque vous utilisez Persona, les assertions d'identité sont passées à la fonction onlogin passée à navigator.id.watch(). Vous devriez toujours envoyer l'assertion au serveur pour vérification, et seul votre serveur devrait décider de donner à l'utilisateur les permissions additionnelles selon le résultat de la vérification:

// Dans navigator.id.watch({ ...
onlogin: function(assertion) {
  // Un utilisateur veut se connecter ! Vous devez:
  // 1. Envoyer l'assertion à votre backend pour vérification et création d'une session.
  // 2. Mettre à jour l'interface.
},

Si vous essayez de vérifier l'assertion en utilisant le JavaScript client, un utilisateur malveillant pourrait usurper l'identité d'un utilisateur légitime en injectant localement du code et en modifiant votre JavaScript. Ceci est possible parce que vous n'êtes pas en contrôle total de ce qui se passe dans le navigateur de l'utilisateur, là où le JavaScript est exécuté.

Encore une fois, vous devriez systématiquement envoyer l'assertion au serveur pour vérification. Même si vous utilisez l'API de vérification locale.

Spécifiez explicitement le paramètre audience

Pour vérifier une assertion, vous pouvez envoyer une requête POST à l'adresse https://verifier.login.persona.org/verify. La requêtre inclut un paramètre appelé audience :

assertion=<ASSERTION>&audience=https://monsite.com:443"

Le paramètre audience est requis. Vous devriez toujours spécifier l'audience explicitement dans votre code, où dans votre configuration. Attention à :

Ne pas croire le header Host envoyé par le navigateur.
Ne pas croire un paramètre explicite envoyé par le navigateur, mais généré par votre JavaScript en utilisant par exemple document.location.

Si vous faites confiance au navigateur pour vous fournir l'audience, alors il devient possible pour un site malveillant de réutiliser les assertions de son site pour se connecter sur votre site.

Vérifier les certificats SSL

Pour vérifier une assertion, vous pouvez envoyer une requête POST à l'adresse https://verifier.login.persona.org/verify. Vous devez vous assurer que la requête HTTPS vérifie le certificat envoyé par le serveur contre un certificat-racine sûr. Si vous ne le faites pas, alors un hacker pourrait se faire passer pour verifier.login.persona.org et renvoyer des vérifications erronées.

Vérifiez que la librairie utilisée vérifie les certicicats correctements, et que vous l'intialisez avec les certificats-racines appropriés.

Par exemple, le module standard de Python 2.7 ne valide pas les certificats serveurs. Nous recommandons plutôt d'utiliser les modules "requests" (en) ou "urllib3" (en) en Python 2.x, ou la classe standard http.client.HTTPSConnection en Python 3.x. En Perl, assurez-vous d'utiliser au moins la version 6.0 de libwww-perl. En fonction du langage, de la bibliothèque et du système d'exploitation utilisé, vous pourriez devoir fournir soit une liste de certificats-racines sûrs, soit le seul certificat utilisé par verifier.login.persona.org.

Implémenter une protection CSRF

Lors d'une attaque de connexion CSRF (Cross-Site Request Forgery, contrefaçon de requêtes trans-sites), un hacker utilise une contrefaçon de requête trans-site pour connecter un utilisateur sur un site en utilisant ses identifiants.

Par exemple : un utilisateur visite un site web malveillant contenant un élément form. L'attribut action du formulaire est défini sur une requête HTTP POST pointant vers https://www.google.com/login, en envoyant le nom d'utilisateur et le mot de passe du hacker. Lorsque l'utilisateur envoie le formulaire, sa requête est envoyée à Google, la connexion est faite avec succès et le serveur Google définit un cookie dans le navigateur de l'utilisateur. À présent, l'utilisateur est sans le savoir connecté sur le compte Google du hacker.

Cette attaque peut être utilisée pour récupérer des informations sensibles à propos de l'utilisateur. Par exemple, la fonctionnalité d'Historique Web de Google recense tous les mots-clefs de recherche de l'utilisateur. Si l'utilisateur est connecté sur le compte Google du hacker ayant la fonctionnalité d'Historique Web activée, alors l'utilisateur donne toutes ses informations au hacker.

Les attaques de connexion CSRF, et les défenses potentielles à mettre en place contre elles, sont documentées plus exhaustivement dans Défenses robustes contre les contrefaçons de requêtes trans-sites (PDF, en). Elles ne sont pas spécifiques à Persona : la plupart des mécanismes de connexion sont potentiellement vulnérables face à elles.

Il y a plusieurs techniques qui peuvent être utilisées pour protéger un site contre les attaques de connexion CSRF, qui sont documentées plus exhaustivement dans l'étude ci-dessus.

Une de ces approches est de créer un identifiant secret dans le serveur, partagé avec le navigateur et de demander au navigateur de le fournir lors de requêtes de connexions. Par exemple :

Dès que l'utilisateur arrive sur votre site, avant qu'il n'essaie de se connecter, créez une session pour lui sur le serveur. Enregistrez l'ID de la session dans un cookie de navigateur.
Sur le serveur, générez une chaîne de caractères aléatoire d'au moins 10 caractères alphanumériques. Un UUID généré aléatoirement est une bonne solution. C'est le jeton CSRF. Enregistrez-le dans la session.
Donnez le jeton CSRF au navigateur en l'incluant dans du JavaScript ou dans le HTML en tant que variable de formulaire cachée.
Assurez-vous que les envois AJAX ou les requêtes POST de formulaires incluent le jeton CSRF.
Côté serveur, avant d'accepter une assertion, assurez-vous que le jeton CSRF envoyé correspond au jeton CSRF enregistré dans la session.

Améliorations

Politique de sécurité du contenu (CSP)

La Politique de sécurité du contenu (CSP) est une couche supplémentaire de sécurité qui aide à détecter et atténuer certains types d'attaques, dont le Scriptage Trans-sites (XSS) et les attaques d'injection de données. Ces attaques sont utilisées pour beaucoup de choses du vol de données à la dégradation du site ou la distribution de logiciels malveillants.

Si vous utilisez la CSP sur votre site, vous devriez modifier votre politique pour inclure Persona. En fonction de votre politique, vous pourriez avoir besoin de :

Supprimer les URI javascript: les remplacer par du code chargé depuis un fichier de script additionnel. Ce fichier peut parcourir les éléments d'après leur ID et attacher des événements aux éléments en modifiant la propriété onclick ou en apppelant addEventListener().
Autoriser https://login.persona.org aussi bien en tant que script-src qu'en tant que frame-src afin que votre site puisse charger le fichier include.js local et que ce fichier puisse communiquer avec l'implémentation alternative de Persona.

Une configuration Apache d'example pourrait inclure :

Header set X-Content-Security-Policy: "default-src 'self'; frame-src 'self' https://login.persona.org ; script-src 'self' https://login.persona.org"