1. The OWASP Foundation
http://www.owasp.org
Ruby on Rails et la
sécurité
(une introduction)
Sébastien Gioria
OWASP France Leader
OWASP Global Education Committee
Confoo.ca
01 Mars 2012 - Montréal - Canada
Sunday, March 4, 12
2. http://www.google.fr/#q=sebastien gioria
‣Responsable de la branche Audit S.I et Sécurité
au sein du cabinet Groupe Y
‣OWASP France Leader & Founder - Evangéliste
‣OWASP Global Education Comittee Member
(sebastien.gioria@owasp.org)
‣Responsable du Groupe Sécurité des
Applications Web au CLUSIF
Twitter :@SPoint
CISA && ISO 27005 Risk Manager
‣ +13 ans d’expérience en Sécurité des Systèmes d’Information
‣ Différents postes de manager SSI dans la banque, l’assurance et les télécoms
‣ Expertise Technique
- PenTesting,
- Secure-SDLC
- Gestion du risque, Architectures fonctionnelles, Audits
- Consulting et Formation en Réseaux et Sécurité
2
2
Sunday, March 4, 12
3. http://www.google.fr/#q=sebastien gioria
‣Responsable de la branche Audit S.I et Sécurité
au sein du cabinet Groupe Y
‣OWASP France Leader & Founder - Evangéliste
‣OWASP Global Education Comittee Member
(sebastien.gioria@owasp.org)
‣Responsable du Groupe Sécurité des
Applications Web au CLUSIF
Twitter :@SPoint
CISA && ISO 27005 Risk Manager
‣ +13 ans d’expérience en Sécurité des Systèmes d’Information
‣ Différents postes de manager SSI dans la banque, l’assurance et les télécoms
‣ Expertise Technique
- PenTesting,
- Secure-SDLC
- Gestion du risque, Architectures fonctionnelles, Audits
- Consulting et Formation en Réseaux et Sécurité
2
2
Sunday, March 4, 12
16. Ce que dit le CIO : mais j’ai un Firewall !!!
27
Sunday, March 4, 12
17. Ce que dit le Commercial : J’ai un certificat
SSL
28
Sunday, March 4, 12
18. Ce que dit le commercial : il faut être un expert pour
hacker des sites Web
• Les outils sont simples d’emploi
• Cherchez juste sur Internet un outil
nommé SQLInjector
• L’attaque d’un serveur Web coute de 100$
à 200$ sur le marché souterrain
• Les hackers “offrent” leur service
directement sur Internet.
29
Sunday, March 4, 12
20. Ce que dit l’utilisateur : Une vulnérabilité
n’est pas importante sur un site Web
interne
•Faut, vu que le web est partout, des attaques comme
CSRF ainsi que l’arrivée de HTML5 et CORS sont
destructrices.
•Souvenez vous, et partagez cela :
• AJAX fait des choses sans que vous le
sachiez...
30
•Sachez et partagez ceci:
• HTML5 introduit de bien belle facilités utilisateur,
mais avec un impact important sur la sécurité
(WebSocket, CORS, ...)
Sunday, March 4, 12
23. ‘OR 1==1 --’
L’injection SQL fait beaucoup parler d’elle.
Mais il existe d’autres formes d’injections :
•XML
•XPath
•LDAP
•ORB(Hibernate)
•...
15
Sunday, March 4, 12
24. ‘OR 1==1 --’
L’injection SQL fait beaucoup parler d’elle.
Mais il existe d’autres formes d’injections :
•XML
•XPath
•LDAP
•ORB(Hibernate)
•...
15
Sunday, March 4, 12
25. ‘OR 1==1 --’
L’injection SQL fait beaucoup parler d’elle.
Mais il existe d’autres formes d’injections :
•XML
•XPath
•LDAP
•ORB(Hibernate)
•...
A1
-‐
Injec*on
15
Sunday, March 4, 12
26. ‘OR 1==1 --’
L’injection SQL fait beaucoup parler d’elle.
Mais il existe d’autres formes d’injections :
•XML
•XPath
•LDAP
•ORB(Hibernate)
•...
A1
-‐
Injec*on
15
Sunday, March 4, 12
27. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
16
Sunday, March 4, 12
28. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
16
Sunday, March 4, 12
29. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
http://www.example.com/Project.rb?name=me
16
Sunday, March 4, 12
30. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
http://www.example.com/Project.rb?name=me
SELECT * FROM Project WHERE name= ‘me’
16
Sunday, March 4, 12
31. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
http://www.example.com/Project.rb?name=me
SELECT * FROM Project WHERE name= ‘me’
Imaginons un accès différent :
16
Sunday, March 4, 12
32. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
http://www.example.com/Project.rb?name=me
SELECT * FROM Project WHERE name= ‘me’
Imaginons un accès différent :
http://www.example.com/Project.rb?name=me ‘ or ‘1’=’1
16
Sunday, March 4, 12
33. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
http://www.example.com/Project.rb?name=me
SELECT * FROM Project WHERE name= ‘me’
Imaginons un accès différent :
http://www.example.com/Project.rb?name=me ‘ or ‘1’=’1
SELECT * FROM Project WHERE name = ‘me’ or ‘1’=’1’
16
Sunday, March 4, 12
34. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
http://www.example.com/Project.rb?name=me
SELECT * FROM Project WHERE name= ‘me’
Imaginons un accès différent :
http://www.example.com/Project.rb?name=me ‘ or ‘1’=’1
SELECT * FROM Project WHERE name = ‘me’ or ‘1’=’1’
Voir un accès très différent :
16
Sunday, March 4, 12
35. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
http://www.example.com/Project.rb?name=me
SELECT * FROM Project WHERE name= ‘me’
Imaginons un accès différent :
http://www.example.com/Project.rb?name=me ‘ or ‘1’=’1
SELECT * FROM Project WHERE name = ‘me’ or ‘1’=’1’
Voir un accès très différent :
http://www.example.com/Project.rb?name=me'; DELETE FROM
PROJECTS; SELECT * from projects where '1'='1
16
Sunday, March 4, 12
36. Injec-on
de
données
-‐
Exemple
de
code
vulnérable
SQL
Soit le code Suivant
Project.find(:all, :conditions => "name = '#{params[:name]}'")
Imaginons un accès normal :
http://www.example.com/Project.rb?name=me
SELECT * FROM Project WHERE name= ‘me’
Imaginons un accès différent :
http://www.example.com/Project.rb?name=me ‘ or ‘1’=’1
SELECT * FROM Project WHERE name = ‘me’ or ‘1’=’1’
Voir un accès très différent :
http://www.example.com/Project.rb?name=me'; DELETE FROM
PROJECTS; SELECT * from projects where '1'='1
SELECT * FROM projects WHERE name = ''; DELETE FROM
PROJECTS; SELECT * from projects where '1'='1'
16
Sunday, March 4, 12
37. Injection - Prévention
★Valider les données
★Utiliser les mécanismes des requêtes
paramétrées quand ils sont disponibles
★Minimiser les privilèges de connexion aux bases
★Minimiser les privilèges des utilisateurs de base
17
Sunday, March 4, 12
38. Injection - Prévention
1.Via une validation d’entrée propre
2.Via les requêtes paramétrées
Sunday, March 4, 12
60. Les développeurs peuvent être tentés de créer leur propre gestionnaire de sessions
et d'authentification, mais il s'agit d'une tâche complexe. Il en résulte souvent des
implémentations contenant des faiblesses de sécurité dans des fonctions telles
que: la déconnexion, la gestion des profils, etc. La diversité des implémentations rend la
recherche de vulnérabilités complexe.
21
Sunday, March 4, 12
61. Les développeurs peuvent être tentés de créer leur propre gestionnaire de sessions
et d'authentification, mais il s'agit d'une tâche complexe. Il en résulte souvent des
implémentations contenant des faiblesses de sécurité dans des fonctions telles
que: la déconnexion, la gestion des profils, etc. La diversité des implémentations rend la
recherche de vulnérabilités complexe.
21
Sunday, March 4, 12
62. Les développeurs peuvent être tentés de créer leur propre gestionnaire de sessions
et d'authentification, mais il s'agit d'une tâche complexe. Il en résulte souvent des
implémentations contenant des faiblesses de sécurité dans des fonctions telles
que: la déconnexion, la gestion des profils, etc. La diversité des implémentations rend la
recherche de vulnérabilités complexe.
A3
-‐
Mauvaise
ges*on
des
sessions et de
l’authentification
21
Sunday, March 4, 12
63. Les développeurs peuvent être tentés de créer leur propre gestionnaire de sessions
et d'authentification, mais il s'agit d'une tâche complexe. Il en résulte souvent des
implémentations contenant des faiblesses de sécurité dans des fonctions telles
que: la déconnexion, la gestion des profils, etc. La diversité des implémentations rend la
recherche de vulnérabilités complexe.
A3
-‐
Mauvaise
ges*on
des
sessions et de
l’authentification
21
Sunday, March 4, 12
64. Session en Rails
★HTTP est un protocole sans état
★Ne pas réécrire son mécanisme !
★ Par défaut les cookies de session sont
utilisés avec une entropie suffisante.
★Protéger les ID lors du transfert
• Utiliser SSL
• Utiliser des cookies « secure »
• Utiliser des limitations de path
★Prévoir une seconde autorisation pour les
transferts « sensibles »
22
Sunday, March 4, 12
65. Sessions en Rails
★Exemple de cookie propre :
23
Sunday, March 4, 12
67. A vous ?
Se connecter à :
•http://88.191.152.70:8080/ePoney-0.0.1-
SNAPSHOT/pages/readReviews
•Choisir “Jack Daniels System” et Show
Reviews
•Attendre 2mns30 :)
25
Sunday, March 4, 12
69. XSS
Le Cross Site Scripting est souvent mal considéré. Sa puissance
peut aller jusqu’a la prise de contrôle sur le poste
client...
26
Sunday, March 4, 12
70. XSS
Le Cross Site Scripting est souvent mal considéré. Sa puissance
peut aller jusqu’a la prise de contrôle sur le poste
client...
26
Sunday, March 4, 12
71. XSS
Le Cross Site Scripting est souvent mal considéré. Sa puissance
peut aller jusqu’a la prise de contrôle sur le poste
client...
A2
-‐
Cross
Site
Scrip*ng
(XSS)
26
Sunday, March 4, 12
72. XSS
Le Cross Site Scripting est souvent mal considéré. Sa puissance
peut aller jusqu’a la prise de contrôle sur le poste
client...
A2
-‐
Cross
Site
Scrip*ng
(XSS)
26
Sunday, March 4, 12
73. XSS - Prevention
★Valider les données en entrée
★Encoder les données de sortie
★ N’accepter que les données attendues. Eviter le cas
‘default’.
★ Nettoyer les données en entrée comme en sortie.
★ N’utiliser que des données fortement typées. Eviter les
‘cast’ implicites ou explicites.
★ Attention aux « clients », qui ne sont pas propres.
27
Sunday, March 4, 12
74. ★Utilisation des échappements HTML
(non suffisant)
★Utilisation des sanitizer HTML (mieux,
mais non suffisant)
★Utilisation de OWASP ESAPI (beta)
http://rubydoc.info/gems/owasp-esapi-ruby
28
Sunday, March 4, 12
77. CSRF
L’attaquant forge une requête HTTP et amène une victime à la soumettre via une
balise d’image, XSS, ou de nombreuses autres techniques. Si l’utilisateur est
authentifié , l’attaque est un succès.
30
Sunday, March 4, 12
78. CSRF
L’attaquant forge une requête HTTP et amène une victime à la soumettre via une
balise d’image, XSS, ou de nombreuses autres techniques. Si l’utilisateur est
authentifié , l’attaque est un succès.
30
Sunday, March 4, 12
79. CSRF
L’attaquant forge une requête HTTP et amène une victime à la soumettre via une
balise d’image, XSS, ou de nombreuses autres techniques. Si l’utilisateur est
authentifié , l’attaque est un succès.
A5
-‐
Cross
site
Request
Forgery
(CSRF)
30
Sunday, March 4, 12
80. CSRF
L’attaquant forge une requête HTTP et amène une victime à la soumettre via une
balise d’image, XSS, ou de nombreuses autres techniques. Si l’utilisateur est
authentifié , l’attaque est un succès.
A5
-‐
Cross
site
Request
Forgery
(CSRF)
30
Sunday, March 4, 12
81. CSRF le probleme
★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.
31
Sunday, March 4, 12
82. CSRF Prevention
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
•
… a ne pas exposer le jeton dans l’entete “referer”
Attention
• 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
32
Sunday, March 4, 12
83. CSRF Prévention en Rails
Par défaut le framework inclut le principe
du jeton
33
Sunday, March 4, 12
84. The OWASP Foundation
http://www.owasp.org
Fuite d’informations
Sunday, March 4, 12
86. Une simple recherche
google permettait d’avoir accès
aux numéros de sécurité sociale
des étudiants de Yale
35
Sunday, March 4, 12
87. Une simple recherche
google permettait d’avoir accès
aux numéros de sécurité sociale
des étudiants de Yale
35
Sunday, March 4, 12
88. Une simple recherche
google permettait d’avoir accès
aux numéros de sécurité sociale
des étudiants de Yale
A6
-‐
Mauvaise
configura*on
Sécurité
35
Sunday, March 4, 12
89. Une simple recherche
google permettait d’avoir accès
aux numéros de sécurité sociale
des étudiants de Yale
A6
-‐
Mauvaise
configura*on
Sécurité
35
Sunday, March 4, 12
90. Prévention
★Garder les outils a jour :
➡Serveurs
➡Frameworks
★Supprimer tous les éléments par défaut
(en particulier les répertoire SVN ?)
★Customiser les messages d’erreurs
36
Sunday, March 4, 12
92. OWASP Top Ten 2010
A3:
Mauvaise
ges*on
A4:Référence
directe
A2:
Cross
Site
A1:
Injec*on des
sessions
et
de
non
sécurisée
à
un
Scrip*ng
(XSS)
l’authen*fica*on objet
A8:
Mauvaise
A5:
Cross
Site
Request
A6:
Mauvaise
A7:
Mauvais
stockage
restric*on
d’accès
à
Forgery
(CSRF)
configura*on
sécurité cryptographique
une
URL
A9:
Protec*on
A10:
Redirec*ons
et
insuffisante
lors
du
transferts
non
validés
transport
des
données
http://www.owasp.org/index.php/Top_10
Sunday, March 4, 12