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

https://www.owasp.org/index.php/Insufficient_Session-ID_Length


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

https://msdn.microsoft.com/en-us/library/system.security.cryptography.rngcryptoserviceprovider(v=vs.110).aspx


« 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

Step1

Step2

https://www.owasp.org/index.php/Session_hijacking_attack


« 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 mesures de 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 courts sur les cookies– Utiliser des délais d’expiration adéquats pour la session

(voir plus loin dans la présentation)– Désactiver les caches d’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 « session ID » 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écanisme ou 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

https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet


« 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 changement de mot de passe)– Garder en mémoire des informations inutiles pour les tâches courantes– Variables de session identiques utilisées par plusieurs processus– Manque de validation des données– Mécanismes inefficients ou incomplets d’authentification et d’autorisation

• Mitigations :– Ne pas remplir les informations de session avant une authentification

réussie

• Plus d’informations ici

https://puzzlemall.googlecode.com/files/Session Puzzles - Indirect Application Attack Vectors - 17 May 2011 - Presentation.pptx


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 « session ID » quand il y a certains évènements importants : connexion, déconnexion et réinitialisation de mot de passe

– Bien comprendre les expirations et leurs interactions

– Les SSO demandent des efforts supplémentaires de 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

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

https://puzzlemall.googlecode.com/files/Session Puzzles - Indirect Application Attack Vectors - 17 May 2011 - Presentation.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

– [email protected]

– [email protected]

mailto:[email protected]

mailto:[email protected]


Merci!

Questions?

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

Internet

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