Notes de cours Sécurité Sécurité Web

Notes de cours Sécurité
Sécurité Web
Morgan Barbier
20 février 2013
1
Certificats
1.1
Problématique
Le protocole TCP/IP a été conçu avec le soucis de robustesse mais pas de
sécurité. Les informations qui sont transmises avec ce protocole circulent en
clair. Il est en est de même pour les cookies.
Pour résoudre ce problème il existe le protocole SSL (Secure Socket Layer),
qui chiffre les communications entre le serveur et le client, ce qui permet d’assurer :
– la confidentialité (chiffrement symétrique avec échange des clés en
asymétrique),
– l’intégrité des paquets (fonction de hachage),
– l’authentification (certificats).
Exemples d’utilisation :
– HTTPS,
– S/POP,
– POP3S,
– S/IMAP,
– Secure cookies.
Principe de base de SSL :
– client demande au serveur son certificat, et donne la liste des systèmes de
chiffrement symétriques qu’il supporte,
– le serveur envoie au client sa clé publique signé par une autorité de
confiance dans un certificat, et choisi un système de chiffrement que les
deux parties supportent,
– le client vérifie la signature de la clé publique, et vérifie s’il fait également
confiance à l’autorité qui a généré le certificat, le client envoie alors au
serveur une clé pour le système de chiffrement symétrique.
1
Le problème est de s’assurer que la clé publique signée est bien celle du
serveur avec lequel on souhaite communiquer, et non un autre serveur ou entité.
C’est pour cela que la notion de certificat est très importante.
1.2
Solution
Certificat :
– rôle : associer un nom de domaine à une clé publique,
– émetteur : une autorité d’authentification (CA),
– informations :
– informations relatives au domaine (nom, organisation...),
– informations relatives à l’autorité d’authentification (nom, organisation...),
– datation du certificat (émission et expiration),
– Empreintes,
– Algorithme asymétrique ainsi que la clé publique associée au domaine.
Le client doit alors vérifier la validité du certificat et que l’autorité d’authentification est bien dans le cercle de confiance du client. Généralement
certaines CA sont déjà enregistrées par défaut dans les navigateurs.
Ce système permet d’éviter les attaques types man-in-the-middle. Mais
attention, c’est le rôle de l’utilisateur de faire attention au hameçonnage
(phishing).
2
2.1
Sessions
Problématique
Après une authentification d’un utilisateur sur un site web, il est nécessaire
de faire transiter tout au long de sa navigation certaines données personnelles
(id...). Si les pages envoie ces données par les méthodes POST ou GET, il est
facile alors pour un attaquant qui est capable de regarder et d’analyser le trafic
d’usurper l’identité d’un utilisateur.
2.2
Solution
L’idée est alors de sauvegardé temporairement ces informations du côté
serveur dans une session. Et on transmet alors un cookie avec l’identifiant de
session, nombre pseudo-aléatoire. Ce qui rends le développement plus facile et
permet d’enregistrer sur le serveur, et non chez le client, des informations importantes, qu’il pourrait avoir envie de modifier, par exemple le prix de son panier...
2
2.3
2.3.1
Risque lié
Usurpation de session
Si pendant la communication du cookie avec l’identifiant de session le
protocole n’est pas sécurisé à l’aide de SSL, alors un attaquant pourrait en
observant les paquets se créer un cookie avec le même identifiant de session et
ainsi usurper l’identification d’un utilisateur.
2.3.2
Cross-site request forgery
Imaginons qu’un utilisateur est connecté à un forum, avec des droits de
modification et/ou de suppression. Dans un autre onglet ce même utilisateur
est sur une page d’un site pirate et sur cette page le site charge la page du
forum avec les commandes de suppression de certaines informations, grâce à la
balise “img”. Alors le forum pensera que l’utilisateur à fait lui-même la requête
de suppression et exécutera cette requête.
Comment s’en prémunir au niveau du forum :
– demander confirmation à l’utilisateur, via mot de passe ou captcha,
– jetons de validité,
– vérifier de quelle page vient la requête $ SERVER[’HTTP REFERER’],
attention cette valeur est modifiable.
3
htaccess
3.1
À quoi ça sert ?
– gère l’authentification des utilisateurs sur certains parties d’un site,
– gérer les erreurs,
– changer les variables PHP : php value nom de variable valeur.
3.2
Risque lié
Il faut faire attention où sont enregistrer ses fichiers. La bonne coutume est
d’enregistrer ces fichiers dans un dossier où se trouve un fichier htaccess avec
Deny from all, rendant l’accès impossible depuis les protocoles HTTP(S). De
plus, grâce à la commande htpasswd, il faut enregistrer les mots de passe de
manière sécurisée.
4
Règles de base
– Toujours récupérer les variables par la méthode utilisée
– $ GET[’....’]
– $ POST[’....’]
3
– $ SESSION[’....’]
– $ SERVER[’....’]
– ...
Pour s’assurer de ne pas faire d’oubli à cette règle mettre la variable de
configuration de PHP : register globals à off.
– Injection : penser toujours à vérifier la forme des variables et les traı̂ter
avec des fonctions qui annulent l’effet des caractères spéciaux :
– mysql real escape string(),
– intval(),
– ...
– Brute-force : pour éviter ce genre d’attaque, penser à regarder les IP de
ceux qui font des requêtes sur le site.
4