top10 risk in app sec fr

Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation http://www.owasp.org/

Les 10 plus importants risques dans vos applications

Sébastien Gioria

OWASP Global Education committee OWASP French Chapter Leader

[email protected]

Votre application va être piratée Laisssez moi vous mettre

dans la bonne direction

2

Votre application

va être piratée

Votre application

a été piratée

OUI

NON

NON

OUI

Ne soyez pas le prochain !

Fire

wal

l

Hardened OS

Web Server

App Server

Fire

wal

l

Dat

abas

es

Lega

cy S

yste

ms

Web

Ser

vice

s D

irect

orie

s H

uman

Res

rcs

Bill

ing

Custom Code

APPLICATION ATTACK

Net

wor

k La

yer

App

licat

ion

Laye

r

Acc

ount

s Fi

nanc

e A

dmin

istra

tion

Tran

sact

ions

C

omm

unic

atio

n K

now

ledg

e M

gmt

E-C

omm

erce

B

us. F

unct

ions

HTTP request

SQL query

DB Table

HTTP response

"SELECT * FROM accounts WHERE

acct=‘’ OR 1=1--’"

1. L’application fourni un formulaire 2. L’attaquant envoi son attaque dans les données du formulaire 3.L’application transfère les données à la requête SQL

Account Summary

Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293

4. Le SGBD lance la requête contenant l’attaque et renvoie les résultats à l’application.

5. L’application renvoie ce résultat à l’utilisateur

Account:

SKU:

Account:

SKU:

A1 – Injection

• Envoyer à une application des données générant un comportement non attendu.

L’injection

• Utilisent les chaines et les interpretent comme des commandes • SQL, OS Shell, LDAP, XPath, Hibernate, etc…

Les Interpréteurs

• Enormément d’applications y sont sensibles • Même s’il est très simple de s’en affranchir….

L’injection SQL est toujours commune

• Souvent très sévère. Le plupart du temps l’ensemble des données de la base sont lisibles ou modifiables.

• Cela peut même aller jusqu’au schéma de la base, les comptes ou un accès OS….

Impact

A1 – Comment se protéger

Recommandations 1. Se passer des interpréteurs, 2. Utiliser une interface permettant de préparer les requêtes (ex,

prepared statements, or les procédures stockées), 3. Encoder toutes les données fournies par l’utilisateur avant de les

passer à l’interpréteur Toujours effectuer une validation de type “white liste” sur les

données utilisateurs. Minimiser les privilèges dans les bases pour limiter l’impact de la

faille.

References Plus de détails sur http://www.owasp.org/index.php/

SQL_Injection_Prevention_Cheat_Sheet

Que peut-il se passer ?

6

Que se passe-t-il ?

7

Site (www.leboncoin.fr)

Site du pirate (ha.ckers.fr

A2 – Cross-Site Scripting (XSS)

• Des données venant d’un attaquant sont envoyées à l’innocent navigateur d’un utilisateur

Se retrouve à chaque audit/pentest

• Stockées en base, • Réfléchies depuis une entrée d’une page Web (champ de formulaire, champ caché, URL, …)

• Envoyées directement à un client Riche (Javascript, Flash, …)

Ces données peuvent être

• Essayez cela dans votre navigateur – javascript:alert(document.cookie)

Virtuellement toute application Web est vulnérable

• Vol des sessions utilisateur, de données sensibles, réécriture de la page Web, redirection vers un site d’hameconnage ou autre code malveillant

• De manière plus grave : installation d’un proxy XSS permettant à un attaquant d’observer le poste client voire de forcer l’utilisateur vers un site particulier

Impact

(AntiSamy)

A2 – Contre mesures

Recommandations Supprimer la faille

Ne pas inclure de contenu fourni par l’utilisateur dans la page de sortie !!!

Défenses possibles 1. Encoder toutes les entrées et sorties utilisateurs (utilisez l’OWASP

ESAPI pour l’encodage de sortie) http://www.owasp.org/index.php/ESAPI

2. Effectuer de la validation de type « white liste » pour les données utilisateurs entrantes qui sont inclues dans une page.

3. Pour des grosses portions de code HTML fourni par un utilisateur, utiliser le filtre OWASP Anti-Sammy de manière à nettoyer l’HTML

Voir: http://www.owasp.org/index.php/AntiSamy Référence

Pour effectuer un encodage propre, se référer à http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet

Que se passe-t-il ?

10

Hacker

Customer

GET /login.jsp?SESSIONID=123456789

OK SESSIONID=12345679 Authenticated

A3 – Mauvaise gestion des sessions et de l’authentification

• Les identifiants doivent donc être passés à chaque requête. • Il faut utiliser SSL pour toute authentification

HTTP est un protocole sans état

• Des ID de sessions sont utilisés pour maintenir la session dans HTTP car il ne le peut lui. • Cela suffit à un attaquant, c’est aussi interessant qu’un identifiant

• Les ID de sessions sont souvent exposés dans les sessions réseau, dans les browsers (cookies), dans les logs, ….

Failles dans la gestion de l’authentification

• Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe, questions secretes, logout, email, …

Attention aux portes dérobées…

• Vol de session ou compromission de comptes utilisateur

Impact

A3 – Contre Mesure

Vérifier l’architecture ! L’authentification doit être simple, centralisée et standardisée Utiliser le mécanisme standard de gestion des cookies du

framework (ils sont globalement fiables) Utiliser constamment SSL pour protéger les identifiants de

connexion et de sessions Vérifier l’implémentation

Oublier l’analyse automatique Vérifier le certificat SSL (SSLv2, renégociation, chiffrement faible,

…) Examiner toutes les fonctions relatives a l’authentification Vérifier que la déconnexion supprime bien la session ! Utiliser l’OWASP WebScarab pour tester l’implémentation

(sessionID analysis)

Que se passe-t-il ?

A4 – Référence directe non sécurisée à un objet

• C’est une manière de renforcer les habilitations en lien avec A7 – Mauvaise restriction d’accès à une URL

Comment accéder aux données privées

• Attendre uniquement de l’utilisateur des accès à des objets autorisés ou • Cacher des références à des objets dans des champs cachés • … et ne pas renforcer les restrictions coté serveur. • Ceci n’est qu’une tentative de contrôle d’accès sur la présentation et ne

fonctionne pas ! • Un attaquant n’a qu’a modifier les valeurs des paramètres…

Des erreurs classiques

• Un utilisateur a accès à des données ou des fichiers normalement interdits

Impact


Eliminer la référence directe. La remplacer par une valeur temporaire aléatoire (e.g. 1, 2, 3) L’ESAPI fournit des fonctions pour cela

IntegerAccessReferenceMap & RandomAccessReferenceMap

Valider la référence directe à l’objet Vérifier que le contenu est correctement formaté. Vérifier que l’utilisateur a le droit d’effctuer l’accès à l’objet. Vérifier que le mode d’accès à l’objet est autorisé (e.g., read,

write, delete)

http://app?file=1 Report123.xls

http://app?id=7d3J93 Acct:9182374 http://app?id=9182374

http://app?file=Report123.xls Access

Reference Map

Que se passe-t-il ?

16

Surf the Web

A5 – Cross Site Request Forgery (CSRF)

• C’est une attaque ou le navigateur de la victime génère une requête vers une application Web vulnérable

• Cette vulnérabilité est causée par la capacité que les navigateurs ont d’ envoyer automatiquement des données d’authentification (session ID, IP adresse, comptes de domaine windows, ..) dans chaque requête.

Cross Site Request Forgery

• Que se passerait-il si un attaquant pouvait utiliser votre souris pour effectuer des clicks sur votre site de banque en ligne a votre place.

• Que pourrait-il faire ?

Imaginez

• Initiation de transactions (transfert de fonds, logoff, modification de données, …)

• Accès à des données sensibles • Changement des mots de passes/identifiants

Impact

CSRF démystifié

Le problème Les navigateurs Web incluent automatiquement la plupart des

identifiants dans chaque requête. Que cela soit des requêtes venant d’un formulaire, d’une image ou

d’un autre site.

Tous les sites basés uniquement sur les identifiants automatiques sont vulnérables Approximativement 100% des sites le sont…

C’est quoi un identifiant automatique? Cookie de session Une entête d’authentification HTTP Une adresse IP Les certificats SSL client L’authentification de domaine Windows.


Ajouter un jeton, non envoyé automatiquement, a toutes les requêtes sensibles. Cela rend impossible pour l’attaquant de soumettre une requête valide.

(sauf si en plus il y a une faille XSS) Ces jetons doivent être surs cryptographiquement.

Options Stocker un seul jeton dans la session et l’ajouter a tous les formulaire et liens

Champ caché: <input name="token" value="687965fdfaew87agrde" type="hidden"/>

Utiliser un URL : /accounts/687965fdfaew87agrde Utiliser un jeton de formulaire: /accounts?auth=687965fdfaew87agrde …

Attention a ne pas exposer le jeton dans l’entete “referer” Utiliser de préférence un champ caché.

Utiliser un jeton unique par fonction. Il est recommandé d’ajouter un second niveau d’authentification pour une

transaction sensible

Ne pas laisser un attaquant stocker des attaques sur le site Encoder proprement les données d’entrées Cela permet de limiter la majorité des interpréteurs de liens

Voir www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet pour plus de détails

Que se passe-t-il ?

20

A6 – Mauvaise configuration

• On pense aux réseaux, aux systèmes et aux plateformes • Il ne faut pas oublier les environnements de développement

Les applications Web doivent faire confiance à une fondation sécurisée

• Pensez a tous les endroits ou l’on trouve votre code source. • La Sécurité ne doit pas se baser sur l’obscurité du code source.

Est-ce que votre code source est secret?

• Tous les identifiants doivent être changés sur les environnements de production

Il faut étendre la gestion de la configuration a toutes les parties de l’application

• Installation d’une porte dérobée via un oubli de patch (serveur, réseau,…) • Failles XSS exploitées du à l’oubli de patch dans les frameworks • Accès non autorisé à des comptes , des données, ou des fonctionnalités

applicatives par défaut non utilisées mais accessibles a cause d’une mauvaise configuration utilisateur

Impact


Vérifier la gestion de la configuration sécurité de vos systèmes. Ayez des guidelines de renforcement de la sécurité.

L’automatisation est réellement utile dans ce cas

Couvrir toute la plateforme et l’application Garder a l’esprit d’avoir des patchs pour TOUS les composants

Cela inclut les librairies, et pas seulement l’OS, les serveurs et applications.

Analyser l’impact sécurité des changements

Pouvez vous effectuer des “masters” de votre configuration applicative ? Mettre en place un reporting des builds dans le processus sécurité Si vous ne pouvez vérifier le configuration applicative, l’applicatif n’est

pas sécurisé

Vérifier l’implémentation Les scans découvrent généralement les configurations par défaut et les

problèmes dus à des patchs de retard

Que se passe-t-il ?

23

A7 – Mauvaise restriction d’URL

• Cela concerne aussi le renforcement des habilitations tout comme le paragraphe A4

Comment protégez vous l’accès à une URL ?

• N’afficher que les liens et menus autorisés dans les listes de choix. • Une fois de plus, c’est du controle d’accès visuel, et cela ne fonctionne

pas. • Il suffit de modifier les requêtes en allant diretement sur les pages

“non autorisées”

Une erreur commune…

• Invocation de fonctions et de services non autorisées • Accès a des données ou des comptes n’appartenant pas à l’utilisateur • Élévation de privilèges et d’actions

Impact


Pour toute URL il faut 3 éléments : Restreindre l’accès aux seuls utilisateurs authentifiés (sauf si l’URL est publique). Renforcer les permissions basées sur les rôles ou l’utilisateue (si l’URL est privée) Bloquer toute requête à des pages non autorisées ( (e.g., fichiers de config, de

log, code source, etc.)

Vérifier l’architecture Utiliser un modèle positif simple a tous les niveaux S’assurer d’avoir un modèle d’accès à tous les niveaux.

Vérifier l’implémentation Oublier l’approche automatisée Vérifier que chaque URL de l’application est protégée par :

Un filtre externe, comme en J2EE (web.xml) Ou par un morceau de VOTRE code – Voir la méthode ESAPI’ isAuthorizedForURL()

Vérifier que la configuration du serveur n’autorise pas les requêtes vers les types de fichiers ou extensions non autorisés.

Utiliser un proxy type WebScarab pour forger des requêtes non autorisées.

Que se passe-t-il ?

26

A8 – Redirections et transferts non contrôlés

• Et fréquemment elles incluent des paramètres fournis par l’utilisateur dans l’URL de destination.

• Si ces paramètres ne sont pas validés, un attaquant peut envoyer la victime vers le site de son choix.

Les redirections sont communes dans une application WEB.

• Ils renvoient la requête vers une nouvelle page en interne de l’application. • Parfois les paramètres déterminent la page cible. • Si cela n’est pas validé, cela permet de parfois passer outre les mécanismes

d’autorisation et d’authentification.

Les transferts(aka Transfer en .NET) sont eux aussi communs

• Rediriger la victime vers un site malveillant de type hameconnage. • Il devient possible de passer outre les contrôles de sécurité et accéder à des

fonctions ou données non autorisées.

Impact

A8 – Contre Mesure Il y a des tonnes de solutions

1. Eviter au maximum les redirections et les transferts 2. S’il faut absolument les intégrer, ne pas utiliser les paramètres parvenant d’un

utilisateur pour définir l’URL/fonction cible. 3. Si vous “devez” utiliser les paramètres utilisateurs,

a) Validez chaque paramètre pour vérifier qu’il est autorisé et valide par rapport à l’utilisateur, ou alors

b) Utilisez une table de correspondance serveur entre les paramètres utilisateurs et les pages à appeler.

Pour les redirection, valider l’URL cible après la construction pour vérifier qu’elle redirige bien vers un site autorisé !

L’ESAPI peut vous aider : Voir : SecurityWrapperResponse.sendRedirect( URL ) http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/

SecurityWrapperResponse.html#sendRedirect(java.lang.String)

Quelques réflexions sur les Transferts Idéallement, il faudrait appeler le contrôle d’accès pour être sur que l’utilisateur

est bien autorisé aà effecgtuer le transfert(très simple avec l’ESAPI…) Si vous utilisez des filtres externes (comme SiteMinder), cela ne sera pas simple La meilleure solution est de s’assurer que les utilisateurs qui ont accès à la page

initiale ont TOUS le droit d’accéder à la page cible….

Que se passe-t-il ?

29

A9 – Stockage Cryptographique non sécurisé

• Oubli d’identification des données sensibles • Oubli d’identification de tous les entrepôts de stockage des

données sensibles. • Bases de données, fichiers, répertoires, fichiers de logs, backup, …

• Oubli de mettre en place une protection correcte des données dans tous les entrepots de stockages des données sensibles.

Le stockage de données non sécurisées

• Modification ou accès a des données confidentielles ou privées (carte de crédits, données santés, données financières, …)

• Extrait de données secretes via d’autres failles (injection SQL, LDAP, …) • Problème d’image de marque, d’image client et perte de confiance • Long et couteux processus de vérification, investigation et retour a la

normale (forensics, lettres et dédommagements client, assurance, …)

Impact


Vérifier l’architecture Identifier toutes les données sensibles Identifier tous les entrepots de stockage des données S’assurer des attaques possibles sur comptes

Utiliser un mécanisme de chiffrement approprié Chiffrement de fichier, de base, d’élément de la base.

Utiliser correctement le mécanisme… Utiliser des algorithmes connus standard et surs. Générer, distribuer et protéger les clefs S’assurer de la capacité de changement régulier des clefs

Vérifier l’implémentation Un algorithme sur est utilisé et c’est le bon algorithme pour la situation ! Toutes les clefs, certificats, et mots de passe sont stockés et protégés correctement. Il existe une distribution propre des clefs et il est possible d’en changer facilement

Que se passe-t-il ?

32

A10 – Protection insuffisante lors du transport des données

• Oubli de l’identification de TOUTES les données sensibles • Oubli de l’identification de TOUTES les URLs/Pages ou les données

sensibles transitent. • Sur le Web, vers les SGBD, vers les partenaires métiers, vers les réseaux

internes… • Oubli de protéger les données à chacun de ces endroits…

La transmission de données non sécurisées…

• Modification ou accès a des données confidentielles ou privées (carte de crédits, données santés, données financières, …)

• Extrait de données secretes via d’autres failles (injection SQL, LDAP, …)

• Problème d’image de marque, d’image client et perte de confiance • Long et couteux processus de vérification, investigation et retour a la

normale (forensics, lettres et dédommagements client, assurance)

Impact


Utiliser les mécanismes de protection appropriés Utiliser TLS pour tout transport de données sensibles. Chiffrer les messages avant transmission.

E.g., XML-Encryption Signer les messages avant transmission

E.g., XML-Signature

Utiliser les mécanismes correctement ! Utiliser des algorithmes surs ! (désactiver les vieilles versions de

SSL et les chiffrements faibles…) Gérer correctement les clefs/certificats. Vérifier les certificats SSL avant l’utilisation. Voir http://www.owasp.org/index.php/

Transport_Layer_Protection_Cheat_Sheet pour plus de details

Résumé…

35

OWASP Top Ten 2010

http://www.owasp.org/index.php/Top_10

En résumé : comment adresser ces risques

Développer du code sécurisé ! Suivre les bonnes pratiques du Guide OWASP sur la construction sécurisée d’une

application Web. http://www.owasp.org/index.php/Guide

Utiliser l’OWASP Application Security Verification Standard comme un guide permettant de définir les mécanismes de sécurité http://www.owasp.org/index.php/ASVS

Utiliser les composants de sécurité standard et s’adaptant le mieux a votre entreprise Par exemple utiliser l’OWASP ESAPI comme une fondation a VOS composants standards http://www.owasp.org/index.php/ESAPI

Auditer les applications Faire appel a une équipe expérimentée pour analyser et auditer l’application. Auditer les applications vous-meme graçe aux guide de l’OWASP

OWASP Code Review Guide: http://www.owasp.org/index.php/Code_Review_Guide

OWASP Testing Guide: http://www.owasp.org/index.php/Testing_Guide

Remerciements - Copyright

Les contributeurs principaux Jeff Williams (auteur du premier Top10 en2003 ) Dave Wichers (auteur et responsible actuel du projet )

Antonio Fontes (OWASP Geneva Chapter) pour certains points

Vous êtes libres de : Partager (copier, distribuer , transmettre) Mixer les slides

Mais uniquement si : Vous le faites a des finalités non-commerciales Et vous continuez à partager vos résultats de la même façon

38

top10 risk in app sec fr

Technology