le développement sécurisé
Embed Size (px)
DESCRIPTION
Une petite présentation que j'avais fait il y a longtemps sur le développement sécuriséTRANSCRIPT

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çon de coder
• Un regard sur les deux cotés
• Etre à l’abris
• Etre polyvalent
• Soyez le maitre

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 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

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

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;

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

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

À 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 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.

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 )

L’attaque

• Ç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)

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

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…

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

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

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

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.

Utilisation normal 1/2 Client légitime
Server Web
www.exemple.com
POST login.php
GET index.php

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.com
Utilisation normal 2/2

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.com

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

FIN