Le développement sécurisé
Kondah Hamza
L’évolution d’un Hacker
Savoir attaquer pour mieux se défendre
• Un art de guerre et un concept
• Une culture avant d’être une mentalité
• Une faç...
Quelques statistiques
Et toujours les mêmes problèmes …
Pour bien comprendre
Passons au choses sérieuses
L’injection SQL
• Consiste à envoyer à une application des données qui vont
générer un bug
• Utilise les chaines et les in...
L’attaque en question
1. L’application fourni généralement un
formulaire/espace login ou autres
2. L’attaquant envoi sa re...
Exemple d’attaque
• Detection : ( sur url )
http://www.mydomain.com/products/products.asp?productid=1’
• URL INJECTION:
ht...
S’en protéger
 Eviter les interpréteurs
 Encoder toutes les données fournies par l’utilisateur
avant de les passer à l’i...
XSS (Cross-Site Scripting)
• Devenue quelque chose d’élémentaire
• Des données venant d’un hacker sont envoyées à la victi...
À l’attaque
Exemple de script
Aller plus loin ? Rechercher les shell XSS
S’en protéger
• Utiliser la fonction htmlspecialchars(), qui convertit les caractères
spéciaux en entités HTML.
• Utiliser...
Mauvaise gestion des sessions et de
l’authentification
• HTTP n’envoie pas les données crypté
• Les identifiants doivent d...
L’attaque
• Ça ressemblera à ça :
• On peut facilement hijacker l’identité de la victime en utilisant
un éditeur de cookies
• Il est...
S’en protéger
▫ Utiliser le flag "Secure" qui permet d’envoyer les cookies via un
canal crypté
▫ Utiliser le mécanisme sta...
Référence directe non sécurisée à un
objet
• une manière de renforcer les habilitations en lien avec
Mauvaise restriction ...
L’attaque
• En changeant le paramètre
en
?id=2
• L’attaquant visualise un
autre compte.
https://www.site-faiiblecom/user?i...
S’en protéger
▫ Vérifier que le contenu est correctement formaté.
▫ Vérifier que l’utilisateur a le droit d’effectuer l’ac...
CSRF (Cross Site Request Forgery )
• C’est une attaque ou le navigateur de la victime génère une requête
vers une applicat...
C’est quoi un identifiant automatique?
▫ Cookie de session
▫ Une entête d’authentification HTTP
▫ Une adresse IP
▫ Les cer...
Utilisation normal 1/2
Client
légitime
Server Web
www.exemple.co
m
POST login.php
GET index.php
Client
légitime Server Web
Liste des objets:
ION Drum [Acheter]
AudioTek [Acheter]
Trump Sonesta [Acheter]
Page suivante |...
L’attaque
Client
légitime
Server Web
www.attaque.com
<html>
<head></head>
<body>
<img
src="http://www.exemple.com/index.ph...
S’en protéger
• Ajouter un jeton, non envoyé automatiquement, a toutes les requêtes
sensibles.
▫ Cela rend impossible pour...
FIN
Prochain SlideShare
Chargement dans…5
×

Le développement sécurisé

576 vues

Publié le

Une petite présentation que j'avais fait il y a longtemps sur le développement sécurisé

Publié dans : Ingénierie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
576
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
21
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Le développement sécurisé

  1. 1. Le développement sécurisé Kondah Hamza
  2. 2. L’évolution d’un Hacker
  3. 3. Savoir attaquer pour mieux se défendre • Un art de guerre et un concept • Une culture avant d’être une mentalité • Une façon de coder • Un regard sur les deux cotés • Etre à l’abris • Etre polyvalent • Soyez le maitre
  4. 4. Quelques statistiques Et toujours les mêmes problèmes …
  5. 5. Pour bien comprendre
  6. 6. Passons au choses sérieuses
  7. 7. L’injection SQL • Consiste à envoyer à une application des données qui vont générer un bug • Utilise les chaines et les interprètent comme des commandes • Une des failles les plus communes • Je dirait LA FAILLE la plus critique • Permet d’accéder et de modifier librement la base de données
  8. 8. L’attaque en question 1. L’application fourni généralement un formulaire/espace login ou autres 2. L’attaquant envoi sa requête bombe dans les données du formulaire 3.L’application transfère les données à la requête SQL 4. Le SGBD lance la requête contenant la bombe et renvoie les résultats que recherche l’attaquant 5. L’application renvoie ce résultat à l’attaquant
  9. 9. Exemple d’attaque • Detection : ( sur url ) http://www.mydomain.com/products/products.asp?productid=1’ • URL INJECTION: http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT username, password FROM USERS • Requete résultante : SELECT ProductName, ProductDescription FROM Products WHERE ProductID = '123' UNION SELECT Username, Password FROM Users;
  10. 10. S’en protéger  Eviter les interpréteurs  Encoder toutes les données fournies par l’utilisateur avant de les passer à l’interpréteur ( Un point à ne pas oublier )  Effectuer une validation de type “white liste” sur les données utilisateurs.  Minimiser les privilèges dans vos bases  Paramétrer les entrées
  11. 11. XSS (Cross-Site Scripting) • Devenue quelque chose d’élémentaire • Des données venant d’un hacker sont envoyées à la victime • Petite idée ? Taper ça sur votre navigateur : javascript:alert(document.cookie) • Vol des sessions utilisateur, de données sensibles, réécriture de la page Web, redirection vers un site d’hameçonnage ou autre code malveillant • installation d’un proxy XSS permettant à un attaquant d’observer le poste client voire de forcer l’utilisateur vers un site particulier
  12. 12. À l’attaque
  13. 13. Exemple de script Aller plus loin ? Rechercher les shell XSS
  14. 14. S’en protéger • Utiliser la fonction htmlspecialchars(), qui convertit les caractères spéciaux en entités HTML. • Utiliser la fonction htmlentities() qui est identique à htmlspecialchars() sauf qu’elle filtre tout les caractères équivalents au codage html ou javascript. • Utiliser strip_tags(), cette fonction supprime toutes les balises. • Ne pas inclure de contenu fourni par l’utilisateur dans la page de sortie !!! ( supprime la faille ) • Effectuer de la validation de type « white liste » pour les données utilisateurs entrantes qui sont inclues dans une page.
  15. 15. Mauvaise gestion des sessions et de l’authentification • HTTP n’envoie pas les données crypté • Les identifiants doivent donc être passés à chaque requête • Les ID de sessions sont souvent exposés dans les sessions réseau, dans les browsers (cookies), dans les logs, • Un sniff et hop • Une seul page en HTTP et c’est faible ( oui il est possible de décrypter les données HTTPS )
  16. 16. L’attaque
  17. 17. • Ça ressemblera à ça : • On peut facilement hijacker l’identité de la victime en utilisant un éditeur de cookies • Il est aussi possible de faire la même chose avec du trafic ssl ( sécurisé ) si il y’a en moins une page dans le site qui est en HTTP ( EX. L’index)
  18. 18. S’en protéger ▫ Utiliser le flag "Secure" qui permet d’envoyer les cookies via un canal crypté ▫ Utiliser le mécanisme standard de gestion des cookies du framework ▫ Utiliser constamment SSL ( sur toutes les pages ) ▫ Vérifier le certificat SSL (SSLv2, renégociation, chiffrement faible, …) ▫ Examiner toutes les fonctions relatives à l’authentification ▫ Vérifier que la déconnexion supprime bien la session ! ▫ Ps : si la configuration SSL n’est pas bien faite , cela entrainera automatiquement une possibilité du décryptage « FACILE » des données de vos utilisateurs
  19. 19. Référence directe non sécurisée à un objet • une manière de renforcer les habilitations en lien avec Mauvaise restriction d’accès à une URL • Un utilisateur a accès à des données ou des fichiers normalement interdits • Un attaquant n’a qu’à modifier les valeurs des paramètres…
  20. 20. L’attaque • En changeant le paramètre en ?id=2 • L’attaquant visualise un autre compte. https://www.site-faiiblecom/user?id=1 L’attaquant note le paramètre id = 1
  21. 21. S’en protéger ▫ Vérifier que le contenu est correctement formaté. ▫ Vérifier que l’utilisateur a le droit d’effectuer l’accès à l’objet. ▫ 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 & RandomAccessReferenceMa
  22. 22. CSRF (Cross Site Request Forgery ) • 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. • Que se passerait-il si un attaquant pouvait utiliser votre souris pour effectuer des clicks sur votre site de banque en ligne à votre place. • Ex . Initiation de transactions (transfert de fonds, logoff, modification de données, …) • Possibilités infinie
  23. 23. 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.
  24. 24. Utilisation normal 1/2 Client légitime Server Web www.exemple.co m POST login.php GET index.php
  25. 25. Client légitime Server Web Liste des objets: ION Drum [Acheter] AudioTek [Acheter] Trump Sonesta [Acheter] Page suivante | Page Precedente <a href="index.php?action=acheter&id=1">Acheter</a> www.exemple.co m Utilisation normal 2/2
  26. 26. L’attaque Client légitime Server Web www.attaque.com <html> <head></head> <body> <img src="http://www.exemple.com/index.php ?action=acheter&id=1"> </body> </html> Server Web www.exemple.co m
  27. 27. S’en protéger • 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 à 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 … • 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
  28. 28. FIN

×