Télécharger en tant que PDF, PPTX
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-27-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-28-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-29-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-30-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-31-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-32-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-33-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-34-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-35-320.jpg)
![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](https://image.slidesharecdn.com/2012-03-01-rorsecurityv01-120304155554-phpapp02/85/2012-03-01-ror-security-v01-36-320.jpg)
Téléchargé parSébastien GIORIA
2012 03-01-ror security v01
Le document présente des problèmes de sécurité associés à Ruby on Rails, notamment des vulnérabilités comme l'injection SQL, le Cross-Site Scripting (XSS) et des lacunes dans la gestion des sessions. Il souligne l'importance de la validation des données, de l'utilisation de requêtes paramétrées et de pratiques de sécurité adéquates pour atténuer ces risques. L'auteur, Sébastien Gioria, partage également son expertise et son expérience dans la sécurité des systèmes d'information.
2012 03-01-ror security v01
- 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
- 4. Agenda •Introduction •Injection •Sessions •XSS •CSRF •Fuite d’informations •Et ensuite... 3 Sunday, March 4, 12
- 5. Etude Verizon 2010 © Verizon 2010 4 Sunday, March 4, 12
- 6. Etude Verizon 2010 © Verizon 2010 4 Sunday, March 4, 12
- 7. Etude Verizon 2010 © Verizon 2010 4 Sunday, March 4, 12
- 8. Etude Verizon 2010 © Verizon 2010 4 Sunday, March 4, 12
- 9. Etude Verizon 2010 © Verizon 2010 5 Sunday, March 4, 12
- 10. Etude Verizon 2010 © Verizon 2010 5 Sunday, March 4, 12
- 11. Etude Verizon 2010 © Verizon 2010 5 Sunday, March 4, 12
- 12. Etude Verizon 2010 © Verizon 2010 5 Sunday, March 4, 12
- 13. 22 © IBM X-Force 2009 - Extrait du rapport 2009 Sunday, March 4, 12
- 14. 23 © IBM X-Force 2009 - Extrait du rapport 2009 Sunday, March 4, 12
- 15. Exposition à unevulnérabilité 26 Sunday, March 4, 12
- 16. Ce que ditle CIO : mais j’ai un Firewall !!! 27 Sunday, March 4, 12
- 17. Ce que ditle Commercial : J’ai un certificat SSL 28 Sunday, March 4, 12
- 18. Ce que ditle 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
- 19. Offres 12 Sunday, March 4, 12
- 20. Ce que ditl’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
- 21. The OWASP Foundation http://www.owasp.org Les risques ! Sunday, March 4, 12
- 22. ‘OR 1==1 --’ 15 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
- 39.
- 40.
- 41.
- 42.
- 43. http://codebutler.github.com/firesheep/ 19 Sunday, March 4, 12
- 44.
- 45.
- 46. mabanque.com 20 Sunday, March 4, 12
- 47. mabanque.com 20 Sunday, March 4, 12
- 48. mabanque.com login.rb 20 Sunday, March 4, 12
- 49. mabanque.com login.rb Requete 20 Sunday, March 4, 12
- 50. mabanque.com login.rb Requete 20 Sunday, March 4, 12
- 51. mabanque.com login.rb Requete Réponse Set-Cookie : SESSIONID=4242 20 Sunday, March 4, 12
- 52. mabanque.com login.rb Requete Réponse Set-Cookie : SESSIONID=4242 mabanque.com 20 Sunday, March 4, 12
- 53. mabanque.com login.rb Requete Réponse Set-Cookie : SESSIONID=4242 Images mabanque.com 20 Sunday, March 4, 12
- 54. mabanque.com login.rb Requete Réponse Set-Cookie : SESSIONID=4242 Images mabanque.com 20 Sunday, March 4, 12
- 55. mabanque.com login.rb Requete Réponse Set-Cookie : SESSIONID=4242 Images mabanque.com Requete Cookie : SESSIONID=4242 20 Sunday, March 4, 12
- 56. mabanque.com login.rb Requete Réponse Set-Cookie : SESSIONID=4242 Images mabanque.com Requete Cookie : SESSIONID=4242 Réponse Cookie : SESSIONID=4242 20 Sunday, March 4, 12
- 57. mabanque.com login.rb Requete Réponse Set-Cookie : SESSIONID=4242 Images mabanque.com Requete Cookie : SESSIONID=4242 Réponse Cookie : SESSIONID=4242 20 Sunday, March 4, 12
- 58. mabanque.com login.rb Requete Réponse Set-Cookie : SESSIONID=4242 Images mabanque.com Requete Cookie : SESSIONID=4242 Réponse Cookie : SESSIONID=4242 20 Sunday, March 4, 12
- 59.
- 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
- 66. The OWASP Foundation http://www.owasp.org Démo XSS 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
- 68. XSS 26 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 échappementsHTML (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
- 75. The OWASP Foundation http://www.owasp.org Démo CSRF Sunday, March 4, 12
- 76. CSRF 30 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 enRails 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
- 85.
- 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
- 91. The OWASP Foundation http://www.owasp.org Conclusion Sunday, March 4, 12
- 92. OWASP Top Ten2010 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
- 93. A lire Ressources OWASP • https://www.owasp.org/index.php/Top10 • https://www.owasp.org/index.php/ Project_Information:template_Ruby_on_Rail s_Security_Guide_V2 • https://www.owasp.org/index.php/Esapi ROR Security Project: • http://www.rorsecurity.info/ 39 Sunday, March 4, 12
- 94. Contact @SPoint sebastien.gioria@owasp.org 40 Sunday, March 4, 12