Spring Security is a framework that provides authentication, authorization, and protection against common attacks. With first class support for both imperative and reactive applications, it is the de-facto standard for securing Spring-based applications.
2. Au niveau d’entreprise le risque de perdre les
données sensibles peut produire des
catastrophes en termes économiques ou
légaux, La sécurité est donc un aspect
important de développement d’une application.
2
3. Spring Security est un module incontournable
d’une application développée en Spring. Il
apporte tout le nécessaire pour sécuriser une
application et il a l’avantage d’être vraiment
personnalisable.
3
4. Quand on parle sécurité applicative, nous avons
deux notions essentielles : l’authentification et
les autorisations. Spring Security essaye
d’apporter une solution à ces deux
problématiques.
4
5. • Spring Security a pour objectif de proposer un
système complet de gestion de la sécurité.
• Ne dépendant pas d’un serveur d’applications
particulier (Tomcat, Jboss,,,)
• Permet de rendre la sécurité complètement
transversale et déclarative.
5
6. Pour configurer votre application vous pouvez
utiliser soit la configuration historique en XML
soit la Java Config. Cette dernière est plus
qu’encouragée avec les dernières versions de
Spring.
6
7. La première étape est de créer un bean de
configuration
7
un filtre de servlet (springSecurityFilterChain)
9. • Par défaut plusieurs fonctionnalités sont activées par
défaut
sécurisation de toutes le URL de l’application
• Génération d’un formulaire par défaut pour
s’authentifier
• Service pour se loguer et se déloguer
• Différentes fonctionnalités pour prévenir les attaques
cross domain,
• ...
9
10. Notre classe de configuration donnée en exemple propose
une configuration par défaut qui est la suivante.
L’URL /login (via un HTTP GET) affiche le formulaire de
login et l’URL /login (via une requête POST) et permet
d’authentifier l’utilisateur.
10
11. C’est bien beau mais j’aimerais bien proposer mon
propre formulaire pour m’authentifier. Rien de plus
simple:
11
12. Vous pouvez être moins restrictif ou plus restrictif sur la
définition des autorisations liées aux requêtes. Par
exemple :
12
13. Je viens de montrer comment sécuriser les requêtes
HTTP mais vous pouvez également restreindre les
droits sur vos méthodes.
13
14. Pour activer la sécurité via les annotations vous devrez
ajouter l’annotation @EnableGlobalMethodSecurity
dans votre classe de configuration.
14
15. 15
Spring Security traite des mécanismes
d'autorisation à base des cookies de session, 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.
20. • Cross Site Request Forgery CSRF: Transmettre
à un utilisateur authentifié une requête HTTP
falsifié qui pointe sur une action sans l’avoir
conscience. CSRF Synchronizer Token
• Cross Site Scripting XSS: Injecter du contenu
dans la page qui provoquant des actions sur
les navigateurs des visiteurs.( exécuter les
commandes Systems , redirection vers un autre site
Hameçonnage, afficher fenêtre authentification résultat sera
envoyé au attaquant ) HTTPonly et secure
20
22. 22
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.
29. • Dans les cookies (recommandé)
1. Les cookies sont utilisées avec HttpOnly ne sont accessible via JavaScript
et sont sécurisés contre XSS,
2. Les cookies sont vulnérables à une attaque CSRF
3. Un cookie ne peut être envoyé qu’au domaine dans lequel il est autorise,
4. Le stockage fournit au moins 4 Mo
• Dans local / session Storage du navigateur
1. Les donnes sont disponibles jusqu'à ce qu’elles soient explicitement
supprimées (LocalStorage)
2. Une fois l’utilisateur ferme la page les données stockées sont
supprimées (SessionStorage)
3. Accessible via JavaScript, cela signifie que JavaScript en cours
d’exécution aura accès au stockage XSS
4. Le stockage fournit au moins 1 Ko
29
35. 35
Les schémas d'authentification basés sur des jetons sont devenus
extrêmement populaires ces derniers temps, car ils offrent des
avantages importants par rapport aux sessions / cookies:
Pas besoin de protection CSRF
Meilleure intégration avec le mobile
Charge réduite sur le serveur d'autorisation
Pas besoin de magasin de session distribué
Plus vulnérable aux attaques XSS
Le jeton d'accès peut contenir des revendications
d'autorisation obsolètes (par exemple, lorsque
certains privilèges d'utilisateur sont révoqués)
36. 36
Les jetons JWT sont de plus en
plus présents sur les applications principalement Frontend et
là où il est nécessaire d’utiliser un même compte utilisateur
sur plusieurs plateformes. Du point de vue de la sécurité, les
jetons JWT sont relativement bien conçus mais présentent
quelques petits inconvénients qu’il faut bien comprendre et
appréhender avant de les implémenter dans une application.
De plus, il ne faut pas perdre de vue que la sécurité entière
du système d’authentification de l’application repose sur
l’algorithme utilisé ainsi que sur la clé privée qui servent à la
signature des jetons. Il faut donc s’assurer de choisir un
algorithme solide et une clé très forte ainsi que garder cette
dernière secrète.
Cet exposé parle de framework Spring : spring security avec jwt
Une ressource représente une entité protégée. Il peut s’agir d’un
fichier, d’une URL ou d’un objet.
Quand on parle sécurité applicative, nous avons deux notions essentielles : l’authentification (savoir qui je suis) et les autorisations (savoir ce que j’ai le droit de faire). Spring Security essaye d’apporter une solution à ces deux problématiques.
Spring Security permet de rendre la sécurité complètement transversale et déclarative.
Une application peut pratiquement être développée entièrement sans se soucier de la sécurité,
la configuration de celle-ci se faisant généralement dans un fichier dédié.
Lors du chargement de ce bean, un filtre de servlet (springSecurityFilterChain) est créé. C’est ce dernier qui orchestrera toute la sécurité (protection des URL, la validation login, mot de passe, ...) au sein de votre application.
Lors du chargement de ce bean, un filtre de servlet (springSecurityFilterChain) est créé. C’est ce dernier qui orchestrera toute la sécurité (protection des URL, la validation login, mot de passe, ...) au sein de votre application.
Lors du chargement de ce bean, un filtre de servlet (springSecurityFilterChain) est créé. C’est ce dernier qui orchestrera toute la sécurité (protection des URL, la validation login, mot de passe, ...) au sein de votre application.
Lors du chargement de ce bean, un filtre de servlet (springSecurityFilterChain) est créé. C’est ce dernier qui orchestrera toute la sécurité (protection des URL, la validation login, mot de passe, ...) au sein de votre application.
Lors du chargement de ce bean, un filtre de servlet (springSecurityFilterChain) est créé. C’est ce dernier qui orchestrera toute la sécurité (protection des URL, la validation login, mot de passe, ...) au sein de votre application.
Lors du chargement de ce bean, un filtre de servlet (springSecurityFilterChain) est créé. C’est ce dernier qui orchestrera toute la sécurité (protection des URL, la validation login, mot de passe, ...) au sein de votre application.
Lors du chargement de ce bean, un filtre de servlet (springSecurityFilterChain) est créé. C’est ce dernier qui orchestrera toute la sécurité (protection des URL, la validation login, mot de passe, ...) au sein de votre application.
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.
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.
Si un compte utilisateur doit être bloqué, il faudra attendre que le jeton expire pour que le blocage soit effectif
Si un utilisateur veut changer son mot de passe (par exemple en cas de piratage de son compte) et si l’authentification a été effectuée juste avant, le jeton généré grâce à l’ancien mot de passe sera toujours valide jusqu’à expiration
Pas de refresh de jeton possible dans l’implémentation standard, ce qui veux dire que lorsque le jeton expire, l’utilisateur doit s’authentifier à nouveau
Il n’est pas possible de détruire un jeton tout en respectant la notion de “stateless” des jetons JWT, car même si on supprime un jeton du navigateur, celui-ci est toujours valide jusqu’à expiration, donc pas de réelle déconnexion possible