OWASP Québec - Attaques et techniques de défense des sessions Web - par Louis Nadeau

1 | WWW.BENTLEY.COM | © 2016 Bentley Systems, Incorporated
Sécurité de la session
Louis Nadeau

Qui suis-je?
• Gestionnaire de la sécurité applicative chez Bentley Systems
• « L’équipe de sécurité applicative est principalement
responsable de défendre une plateforme Cloud (sur Microsoft
Azure) appelée Bentley CONNECT. Celle-ci permet aux
applications mobiles, de bureaux et serveurs d’effectuer des
simulations, de la manipulation de données géospatiales, de la
surveillance d’infrastructure, etc. L’équipe est aussi
responsable de la sécurité de tous les produits Bentley (>600)
et coordonne un réseau de plus de 130 champions de la
sécurité »
• Aussi vice-leader d’OWASP Québec 

Bentley Systems
• « Fondé en 1984, Bentley compte aujourd’hui plus de 3 000 collaborateurs
dans 50 pays, pour un chiffre d’affaires annuel de 600 millions de dollars.
Depuis 2005, Bentley a investi plus de 1 milliard de dollars dans la
recherche, le développement et les acquisitions. »
• « Bentley est le premier fournisseur mondial de solutions logicielles
dédiées aux architectes, aux ingénieurs, aux professionnels du secteur géo-
spatial, aux constructeurs et aux propriétaires-exploitants de
l’infrastructure mondiale. Bentley utilise la mobilité de l’information pour
améliorer la performance des actifs liés à l’infrastructure en exploitant au
mieux la modélisation des données au travers de projets intégrés pour une
infrastructure intelligente. Ses solutions comprennent la plateforme
MicroStation pour la conception et la modélisation de l’infrastructure, la
plateforme ProjectWise pour la collaboration en équipe et le partage des
tâches sur des projets d’infrastructure et la plateforme AssetWise pour les
opérations sur les installations d’infrastructure »

Plan
• Intro
• Attaques et défenses des sessions
• Autres sujets connexes

Intro

Qu’est-ce qu’une session ?
• OFQ 1997 :
– « Période de temps continue qui s'écoule entre la connexion et la
déconnexion à un réseau ou à un système, ou encore entre
l'ouverture et la fermeture d'un logiciel d'application. »
– « Une session peut donc être le temps pendant lequel un utilisateur
est connecté à un ordinateur ou pendant lequel plusieurs
ordinateurs communiquent entre eux (dans ces cas-là, on peut parler
de session de communication).Une session est aussi le temps
pendant lequel un utilisateur se sert d'un logiciel d'application (dans
ce cas-là, on peut parler de session de travail). »

Pourquoi utiliser des sessions?
• Pour
– Minimisation du transport de données sensible:
• Jeton de sécurité ou du mot de passe
– Plus pratique et ergonomique pour l’utilisateur
• Contre
– Implique plus de code
– Augmente la surface d’attaque
– Plus complexe à défendre

OWASP et session
• OWASP Top 10
– A1 Injection
– A2 Broken Authentication and Session Management
– A3 Cross-Site Scripting (XSS)
– A4 Insecure Direct Object References
– A5 Security Misconfiguration
– A6 Sensitive Data Exposure
– A7 Missing Function Level Access Control
– A8 Cross-Site Request Forgery (CSRF)
– A9 Using Components with Known Vulnerabilities
– A10 Unvalidated Redirects and Forwards

Session ≠ « cookies »
• En général : les cookies sont un moyen de
transporter et d’enregistrer l’identifiant de
session (Session ID)
• Quelquefois : toute la session peut être
dans le cookie lui-même (« stateless »)
– Exemple ASP.NET WIF : FedAuth
– Danger 1 : cookie crypté et signé qui contient
les « claims », les données de session et les
valeurs d’expiration
– Danger 2 : limite à la taille des cookies
• 4ko-16ko/cookie
• 20-100 cookies/domaine
• « Max header size »

Attaques et défenses

Types d’attaque sur les sessions
• « Session Hijacking Attack »
• « Session Fixation Attack »
• « Session Donation Attack »
• « Session Puzzling »

« Session Hijacking »
• « Session Hijacking attack compromises the session token by
stealing or predicting a valid session token to gain
unauthorized access to the Web Server.» --OWASP Web Site
• Le « session ID » peut être compromis de diverses façons, les
plus communes sont :
– « Session ID » prédictible
– Attaque sur le client (XSS, JavaScript malicieux, Trojan, etc.)
– « Man in the browser attack »
– « Session Sniffing »
– « Man in the middle (MITM) »

« Session Hijacking » : « Session ID » prédictible
• Voici le nombre de secondes attendu pour trouver le « session ID »
quand on fait une recherche force brute (détails) :
ҧ𝑡 =
2 𝐵
+ 1
2𝐴 ∙ 𝑆
• B est le nombre de bits d’entropie dans le « session ID »
• A est le nombre d’essaies par seconde
• S est le nombre de sessions valides
• Exemples :
– ASP.NET_SessionId=user01 ->B=6.64,A=1,S=1
• ≈50 sec
– ASP.NET_SessionId=e195581df71759985a96b9841ec0bc41 ->B=128,A=1,S=1
• ≈5x1030 years

« Session Hijacking » : « Session ID » prédictible
• Mitigation : utilisation de « session ID » très long
– Par exemple, en .NET utiliser RNGCryptoServiceProvider
• Erreurs de compréhension courantes :
– Un GUID est garanti contre les collisions, mais n’est pas garanti d’être
aléatoire
– Même si aléatoire (GUID v4), c’est pseudo-aléatoire, donc ça ne
résiste pas à une analyse cryptographique
• L’état interne peut être deviné

« Session Hijacking » : Attaque sur le client
• XSS
– <SCRIPT>alert(document.cookie);</SCRIPT>
– Mitigation : validation en entrée, encodage et
filtrage en sortie
• JavaScript malicieux (Ads)
– Mitigation Serveur : utiliser uniquement des
scripts venant de sources fiables
– Mitigation Client : Ads blocker
• Malware, spyware, etc.
– Mitigation : hygiène informatique (antivirus, ne
pas cliquer courriel, etc.)

« Session Hijacking » : « Sniffing »
• Applicable à :
– « Session sniffing »
– « Man in the middle »
– « Man in the browser »
• Voir OWASP
Step
1
Step
2

« Session Hijacking » : « Session Sniffing »
• Mitigations primaires :
– Sécurité du canal de transport
• Utiliser uniquement HTTPS
• TLS1.1 & 1.2
• Utiliser des algorithmes sécuritaires
– Fermer HTTP (pas juste rediriger)
• « Downgrade attack »
– Utiliser HSTS et HPKP

« Session Hijacking » : « Session Sniffing »
• Mitigations secondaires (« Security in depth »):
– Mettre des mesuresde sécurité sur les cookies:
• Flag « HttpOnly » et « Secure »
– Ne pas faire perdurer les cookies(« persistent»)
• Désactiver « auto-restore » dans les navigateurs
– Mettre des délais d’expiration courtssur les cookies
– Utiliser des délais d’expiration adéquats pour la session
(voir plus loin dans la présentation)
– Désactiver les cachesd’information en utilisant les
entêtes:
• Cache-Control: private, no-cache, no-store, max-age=0, no-
transform
• Pragma: no-cache
• Expires: 0
– Ne pas passer le « sessionID » par l’URL
• Mitigations tertiaires :
– Antivirus
– Minimiser les « plugins » de navigateur et les garder à
jour

« Session Fixation Attack »
1. L’attaqueur choisi un « session ID »
2. L’attaqueur trouve une façon de
définir son « session ID » dans la
cible
3. L’attaqueur attend
4. La cible envoie son mot de passe
sous le « session ID » malicieux
5. L’attaqueur a accès à la session et
aux données associées
• #2 et #4 sont les points de mitigation

• Mitigations primaires :
–Ne permettre aucun mécanisme pour définir un « session
ID » côté client
• Notamment, ne pas utiliser l’URL pour le « session ID » :
– GET www.bestappevar.com/?JSESSIONID=AttackerControledStuff
– Peut être exploité par des courriels de « phishing »
– Erreur fréquente : certains langages permettent de changer des variables internes si
passées en paramètre dans l’URL
» S’assurer que ce n’est pas le cas
» Si c’est le cas, désactiver ce mécanismeou défendre les variables importantes
(exemple : URL rewriting)
–Après une authentification réussies, changer le « session ID »

• Mitigations secondaires :
– Détruire la session quand il y a un
changement de mot de passe
– Détruire la session quand l’utilisateur
se déconnecte
• Empêche le pirate de continuer d’utiliser
une session active
• Le bouton « back » ne devrait pas
fonctionner après une déconnexion
• ASP.NET est problématique car
« stateless »
• Ne peut pas être fait complètement dans
un contexte« stateless »
– Garder des délais d’expiration courts

DÉMO

« Session Donation »
• Un attaqueur force quelqu’un à s’authentifier
en utilisant un compte malicieux
– L’attaqueur espère que la cible va entrer des
données sensibles comme des données de carte
de crédit qui pourront ensuite être réutilisées
– Pratique dans des scénarios où la validation ne
s’effectue qu’au début
• Souvent exploitée par une variante des « Cross
Site Reference Forgery (CSRF) », mais sur une
page d’authentification

« Session Donation »
• Mitigation : utilisation de mesures anti-CSRF sur la page de
connexion et de déconnexion
– Des jetons Anti-CSRF (AFT : « anti-forgery token ») peuvent être
utilisés
– Voir bonnes pratiques de l’OWASP ici :
https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
– Utilisation du « synchroniser » ou « double submit cookie pattern »
– Ces jetons peuvent être vus comme des « session ID »
supplémentaires

« Session Puzzling »
• Exploitable quand une séquence d’accès à des pages publiques
donne accès à des pages authentifiées, sans avoir à entrer de mots
de passe
• Causes :
– Remplissage prématuré des objets de sessionà partir de pages publiques
(exemple : page de changementde mot de passe)
– Garder en mémoire des informationsinutiles pour les tâches courantes
– Variables de sessionidentiques utilisées par plusieurs processus
– Manque de validation des données
– Mécanismesinefficientsou incompletsd’authentificationet d’autorisation
• Mitigations :
– Ne pas remplir les informationsde sessionavant une authentification
réussie
• Plus d’informations ici

Autres bonnes pratiques connexes

Expiration de session
• Plus c’est court, plus c’est sécuritaire
– Trouver le juste milieu entre le besoin de sécurité et
l’expérience utilisateur
• Trois types:
– Expiration absolue – demande à nouveau le mot de
passe
– Expiration de renouvellement – redonne une session
valide
– Expiration relative à l’activité (« sliding window »)
• Erreur fréquente : confondre l’expiration de
l’identifiant de session (« cookie ») avec l’expiration
de la session elle-même. Les deux peuvent avoir la
même valeur ou non.
• Gérer les délais d’activation dans un contexte de
« single sign on » ou de fédération peut être
complexe
– Pourrait être le sujet d’une autre conférence

SSO et multiples sessions
• Les bénéfices d’utiliser un « single sign-on » (SSO)
outrepassent les problèmes encourus mais :
– Plusieurs sessions coexistent et doivent être détruites séparément
dans leur système respectif
– Plusieurs ensembles de délais d’expiration existent simultanément et
doivent être cohérents
– La destruction de la session dans une application spécifique ne
termine pas nécessairement la session dans le SSO
• Naviguer dans le SSO peut permettre de revenir dans l’application sans mot
de passe
– Une déconnexion fédérée est nécessaire
• Peut être difficile et est prompt à faire des erreurs

Difficultés de destruction de la session
• Il faut détruire le « session ID » après une déconnexion
• Erreur courante : la destruction du côté client est faite en
remplaçant le session par une valeur nulle, mais dans le
serveur la valeur reste active.
– Faire « back » après une déconnexion ne devrait pas fonctionner
– Peut être difficile dans un contexte « stateless »
• Il faut détruire la session après une réinitialisation de mot de
passe
– Montrer les sessions actives à l’utilisateur et leurs associations à des
IPs ou des machines
• Bien valider le « session ID »
– Une valeur nulle ou invalide devrait retourner à la page
d’authentification

Exemples
• XSS dans déconnexion fédérée
– « Cookie » ou « Relying Party » malicieux
• « Cookies » de session interchangeables entre production et
DEV
• Session infinie quand on utilise Chrome
• « FedAuth cookies » dans des « logs » publics
• « Cookie puzzling »

Détection d’attaques
• Générer des alertes quand :
– Une session expirée est utilisée
– Une valeur de « session ID » invalide est utilisée
– Une même session est utilisées à partir de plusieurs IPs
– Un même utilisateur a plusieurs sessions
– Etc.

Conclusion

Sommaire
• L’utilisation des sessions réduits l’exposition des mots de passe et
des jetons d’authentification, mais rend par contre d’autres types
d’attaques possibles
• Il faut connaitre les types d’attaques sur les sessions ainsi que leurs
mitigations :
– HTTPS
– « Session ID » long et aléatoire
– Changer le « sessionID » quand il y a certains évènementsimportants :
connexion,déconnexionet réinitialisation de mot de passe
– Bien comprendreles expirations et leurs interactions
– Les SSO demandentdes effortssupplémentairesde planification de gestion
de session

Références
• https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
• https://puzzlemall.googlecode.com/files/Session%20Puzzles%20-
%20Indirect%20Application%20Attack%20Vectors%20-
%2017%20May%202011%20-%20Presentation.pptx
• https://www.owasp.org/index.php/Insufficient_Session-ID_Length
• https://msdn.microsoft.com/en-
us/library/system.security.cryptography.rngcryptoserviceprovider(v=vs.110).aspx
• https://www.owasp.org/index.php/Session_hijacking_attack
• https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

Contact
• Louis Nadeau
– Louis.Nadeau@Bentley.com
– Louis.Nadeau@OWASP.org

Merci!
Questions?

OWASP Québec - Attaques et techniques de défense des sessions Web - par Louis Nadeau

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à OWASP Québec - Attaques et techniques de défense des sessions Web - par Louis Nadeau

Similaire à OWASP Québec - Attaques et techniques de défense des sessions Web - par Louis Nadeau (20)

OWASP Québec - Attaques et techniques de défense des sessions Web - par Louis Nadeau