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