Archives de catégories : Technique

Jetons JWT et sécurité – Principes et cas d’utilisation

Sous PHP, la méthode principale pour gérer des sessions utilisateurs est l’utilisation de cookies de sessions appelés par défaut « PHPSESSID ». Lorsqu’un utilisateur se connecte sur une application, celle-ci demande la génération d’un identifiant de session au programme PHP présent sur le serveur Web. Celui-ci s’exécute et créé un code unique qu’il va stocker dans sa mémoire vive puis renvoyer au client grâce au header « Set-Cookie ». Les cookies étant conçus pour être automatiquement renvoyés dans chaque requête du navigateur vers le serveur, l’identifiant de session sera transmis systématiquement. Cette solution permet de gérer les cas classiques de connexion/déconnexion d’un utilisateur.

Cependant, ce type de fonctionnement ne permet pas de partager facilement un même compte pour s’authentifier sur plusieurs plateformes distinctes et le serveur a l’obligation de stocker l’état et les informations des sessions dans sa mémoire vive.

Les jetons JWT quant à eux sont “stateless”, cela signifie que les informations des sessions ouvertes ne sont pas stockées côté serveur. Outre le gain de mémoire que cela procure, les jetons JWT peuvent être utiles si vous souhaitez utiliser les mêmes comptes utilisateurs pour plusieurs applications. Il suffira que les applications utilisent la même clé privée pour signer et vérifier les jetons JWT. Les utilisateurs pourront ainsi s’authentifier une fois sur l’application hébergeant les comptes utilisateurs, puis ils pourront se connecter aux autres applications, celles-ci n’ayant qu’à vérifier la validité des jetons.

Description

Les « JSON Web Token » ou JWT sont des jetons générés par un serveur lors de l’authentification d’un utilisateur sur une application Web, et qui sont ensuite transmis au client.

Ils seront renvoyés avec chaque requête HTTP au serveur, ce qui lui permettra d’identifier l’utilisateur.

Pour ce faire, les informations contenues dans le jeton sont signées à l’aide d’une clé privée détenue par le serveur. Quand il recevra à nouveau le jeton, le serveur n’aura qu’à comparer la signature envoyée par le client et celle qu’il aura générée avec sa propre clé privée et à comparer les résultats. Si les signatures sont identiques, le jeton est valide.

Structure d’un jeton JWT

Si la norme RFC 7519 est bien respectée, un jeton JWT se compose de cette façon :
Une partie “Header”, contenant l’algorithme utilisé pour la signature ainsi que le type de jeton (dans notre cas toujours “JWT »), en JSON encodé en Base64
Une partie “Payload” contenant les informations du jeton, comme par exemple le nom de l’utilisateur, la date d’émission du jeton ou sa date d’expiration le tout en JSON encodé en Base64
Une partie “Signature”, qui correspond à la concaténation des parties “Header” et “Payload” chiffrée avec la clé privée.

Lire la suite

La sécurité des applications mobiles démystifiée – Episode #3

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelle que soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Ce troisième épisode présente les failles liées aux échanges de données

Une application mobile fonctionne rarement en mode non-connecté. Une exception pourrait être une application de type dictionnaire, qui n’a pas besoin de communiquer avec un quelconque serveur pour fonctionner : toutes les données sont déjà présentes dans l’application et l’utilisateur affiche des définitions de mots du dictionnaire.

Mais il s’agit d’un cas bien spécifique, car la plupart des applications mobiles communiquent avec un serveur web.

Données échangées par l’application mobile

Suivant les besoins métier, une application mobile peut être amenée à envoyer ou recevoir différents types de données, comme par exemple :

  • Identifiants de connexion
  • Données de session utilisateur
  • Données personnelles
  • Données transactionnelles liées au métier de l’application
  • Données bancaires

Comment les données sont-elles échangées avec l’extérieur ?

Suivant les cas, différents flux de données peuvent être présents au sein d’une même application.
Prenons l’exemple d’une application ecommerce permettant à ses utilisateurs d’acheter des articles, et de laisser des commentaires.

Les différentes données transférées peuvent être :

  • Données d’identification de l’utilisateur
  • Statistiques d’utilisation de l’application
  • Données relatives aux commentaires sur les produits

Flux de données d'une application mobile

Dans notre exemple, trois serveurs interagissent avec l’application. Certains flux contiennent des données sensibles, d’autres non.

Lire la suite

La sécurité des applications mobiles démystifiée – Episode #2

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelle que soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Ce second épisode présente les failles liées au stockage non sécurisé des données.

Une application mobile peut stocker différents types d’informations :

  • Données de géolocalisation
  • Transactions
  • Identifiants ou tokens d’authentification
  • Données personnelles (PII)
  • Données métier
  • Données mises en cache (stockage temporaire)

Comment les données sont-elles stockées sur l’application?

En fonction de la plateforme (iOS, Android…), différents moyens de stockage peuvent être utilisés. Base de données, fichiers plats, fichiers XML, fichiers Plist, carte de stockage type SD… Des emplacements différents pour des contextes différents.
De plus, les données peuvent être cryptées, plus ou moins efficacement.

Lire la suite

La sécurité des applications mobiles démystifiée – Episode #1

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelque soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Sujet numéro 1 cette semaine : Les contrôles côté serveur

Oui, côté serveur. Le premier des risques ne se situe pas forcément sur l’appareil mobile lui-même, mais sur les serveurs. Voyons pourquoi.

Une application mobile fonctionne assez rarement seule, et communique avec un serveur qui lui fournit des données :

  • Données d’authentification (pour authentifier les utilisateurs)
  • Données métier (pour que l’application sache quelles données afficher à l’utilisateur)
  • Données financières, s’il y a des transactions
  • Données transactionnelles (ventes, RH…)
  • Données de reporting
  • Données personnelles

Sécurité applications mobiles - sécurité du serveur

La partie du serveur qui communique avec l’appareil mobile est appelée l’API, ou le webservice.
Le serveur étant un élément central et global, il y a de fortes chances pour qu’il soit attaqué.

Les possibilités d’attaque sur un serveur sont énormes. L’OWASP édite le top 10 de ces attaques, que nous avons détaillées au cours d’une précédente série d’articles (Comprendre les vulnérabilités web en 5 min – episode #1 : Injections!).

Lire la suite