La sécurité informatique est devenue de plus en plus importante avec la généralisation de l'utilisation d'internet dans la vie quotidienne.

Concernant les applications Web (du site web au logiciel basé sur le web) il convient de les protéger au moins un minimum afin qu'elles ne soient pas détournées de leur utilisation première.

Nous allons faire un tour rapide des différentes attaques que peuvent subir des applications web ainsi que des différents moyens de s'en prémunir. La liste n'est pas exhaustive mais a pour objectif de vous aider à limiter les soucis. Ces exemples seront essentiellement basés sur la plate forme PHP - qui est la plus utilisée aujourd'hui - mais pourront être transposés facilement si vous utilisez ASP, etc..

• Url mal formées
• L'arborescence de votre site
• Injections SQL
• Vols de sessions
• Les attaques de type "man in the middle"
• Mécanismes d'authentification basés sur javascript, Java, ou ActiveX
• Cross site scripting
• Cookie poisoning
• Conclusion

Url mal formées

Intérêt ?

Ces urls malformées envoyées au serveur Web essaient de faire accéder à des zones non autorisées du serveur ou de lui faire exécuter des commandes non prévues.

Voici quelques exemples de ces urls malformées provenant de logs d'Apache.

Exemple

Commentaires

Ces urls mal formées sont provoquées souvent par des scripts ou des virus pour exploiter une faille connue de votre serveur Web.

Que faire ?

Vous n'avez pas grand-chose à y faire, seulement maintenir à jour la version de votre serveur Web.

Complément

• Un exemple de virus :Code red

L'arborescence de votre site

Intérêt ?

Les dossiers de votre site Web vont pouvoir donner des informations intéressantes sur la façon dont être construit votre application.

Ceci n'est pas une faille de sécurité en soit, mais peut permettre notamment de savoir si vous utilisez php en mod cgi, quel est votre dossier d'images pour vous les prendre, etc, etc…

En resumé, ceci peut ammener des gens à consulter des informations que vous n'aviez pas prévu de mettre à disposition; cela peut aider des crackers à trouver des failles dans votre système; Cela peut provoquer une augmentation de la bande passante consommée ralentissant l'affichage de vos pages...

Comment font-ils ?

• En analysant le source de la page :
  Par exemple vous pouvez voir IMG src= " . /pict/my_file.gif " vous en concluez donc qu'il existe un dossier pict à la racine du serveur qui contient les images ; intéressant si vous voulez récupérer toutes les images d'une url
• Soit avec des logiciels qui le font à votre place par rapport à une base de signatures (ex Whisker)

Commentaire

Quelqu'un d'intéressé par vos images par exemple pourra se connecter directement via son client http préferé à http://votre_site/pict/ et avoir une liste de toutes les images qui se trouvent dans votre dossier pict.

Que faire ?

• Pour se protéger contre la recherche automatique de dossiers communs, rien de tel que de nommer vos dossiers d'une façon qui vous est propre, par exemple remplacer /lib/ par ./my_librairies/
• Pour se protéger contre l'accès intempestif des dossiers directement, cas des images, deux possibilités s'offrent à vous:
  • Placez un fichier index.html dans ces dossiers pour que des qu'une personne tente d'accéder directement à ce dossier soit redirigée directement vers ce fichier. Ceci fonctionne avec tous les serveurs Web, si bien sûr sa configuration autorise la redirection sur les pages index.html (cas le plus courant)
  • Si vous êtes sous Apache, vous pouvez utiliser les fichiers htaccess et htpassword pour donner des directives particulières à l'accès d'un dossier

Complément

• Whisker
• Autre scanner web: N-stealth
• class protect_picture

Injections SQL

Intérêt ?

Si votre site Web est un site dynamique, vous devez avoir un serveur de bases de données derrière qui est probablement un serveur SQL. Vous pouvez être sensible à ce genre d'attaques. L'injection SQL consiste en le détournement de données SQL de son but initial. L'exemple le plus flagrant est celui de l'authentification sur un site pour accéder à votre compte. Vous avez un login et un password que vous envoyez à l'aide d'un formulaire au script qui va vérifier votre authentification.

Exemple ?

Ce script - si c'est un script php - pourrait être de la forme suivante :

Comment ?

Qu'est ce qu'il se passe si $_POST['user'] contient " admin' ;# " ? La requête devient SELECT * FROM users WHERE login = 'admin' ;#' AND password = '' Ce qui revient à faire SELECT * FROM users WHERE login = 'admin' , donc de se logguer sous administrateur… Ceci n'est qu'un exemple d'injection SQL, consultez les lectures additionnelles pour plus d'informations.

Que faire ?

• Forcer le type de vos variables avec des intval, strval, etc… ; ceci vous permettra d'avoir que le type attendu
• Utiliser la fonction addslashes et activer les magic_quotes_rpc qui va echapper les caracteres qui pourraient modifier le sens de vos requêtes
• Dans l'exemple présenté, mettre
  select * from users where password = '' and login ='';
• Ne pas mettre le compte administrateur le premier dans votre table…
• Maintenir la version de votre serveur de base de données à jour.
• Etc, etc…

Complément

• Livre blanc sur l'injection SQL

Vols de sessions

Intérêt ?

Les sessions sont utilisées quasiment partout maintenant. Elles permettent d'assurer un suivi du client pendant sa visite sur votre site ceci pour pallier au problème que le protocole http est un protocole non connecté (en d'autres termes, il n'est pas possible au serveur de pouvoir déterminer quel client visite quelle page) Ceci peut se faire de deux façons:

• à l'aide de fichiers de sessions stockés sur le serveur.
• à l'aide de cookies qui sont stockés chez le client.

Dans les deux cas, les sessions vont permettre de stocker des informations personnelles du visiteur. Pouvoir acceder a ces sessions permettra d'acceder à ces données sensibles...Ce n'est pas trop gênant si c'est dans le cas de votre caddie sur amazon qui contient votre liste d'achats, mais plus genant lorsque la session contient des données d'identification...

Exemple ?

Deux méthodes permettent de recuperer un identifiant de session.

• De façon active: le hacker tente de récupérer un identifiant de session valide d'un utilisateur qui vient de se connecter, par des analyses statistiques par exemple.
• De façon passive:dans le cas ou les sessions sont gérées du coté serveur, les liens présentant l'identifiant de session (ex:http://mon_site.com/index.php?PHPSESSID=identifiant_session) etle lien est transmit à une personne tierce; cette personne va
  pouvoir récupérer les informations de la session si elle n'a
  pas encore expirée.
  • La réduction de la durée de la session. plus celle ci sera courte, moins on aura de chance de récuperer un identifiant encore valide d'une session devenue inutilisée.
  • sauvegarder l'adresse ip du client dans la session et à chaque utilisation de la session, vérifier si elle correspond bien au client courant;



Comment?

Dans les deux cas, l'utilisateur recupere l'identifiant d'une session encore valide, et recupere les données qu'elle contient.


Que faire ?

Vous pouvez réduire le risque de vol de sessions, par:

 

si vous vous trouvez sur php5, vous pouvez augmenter la taille du hash de l'identifiant session: intialement cette directive se trouve à 0 (md5) mais vous pouvez la passer à sha-1 qui fait fait passe le hash a 160 bits. Modifiez la directive correspondante dans le php.ini

Complément

• Livre blanc de secureNet Session riding

Les attaques de type 'man in the middle'

Intérêt ?

Ce type d'attaque n'est pas spécifique des applications Web; Une attaque de type "man in the middle" correspond à l'intrusion d'une personne dans une conversation entre 2 personnes (client - serveur)

Exemple ?

Quel est l'intérêt? Vols de mot de passe, de numéro de carte de crédit lors d'un paiement sur un site d'achat en ligne, les raisons sont vastes et variées.

Comment ?

Je ne veux pas faire un cours de hacking, donc je vous laisse vous documenter si vous désirez en savoir plus sur les façons de procéder des hackers.

Que faire ?

Pour empêcher ce type d'attaques, il faut une transaction cryptée entre le client et le serveur par l'intermédiaire d'un serveur https;la présence d'un serveur https assure l'encryption de la communication entre le client et le serveur et de ce fait, ecarte les risques de ce type d'attaque. Par contre, tant que le client ne possède pas de certificat, vous ne pouvez pas assurer que le client qui a saisi le couple login \ password correspondant à votre compte admin est bien l'administrateur de l'application. Le seul moyen d'assurer que vous communiquez bien avec la personne voulue et que personne n'écoute la communication est que le client et le serveur possèdent un certificat

Complément

• Evaluer les risques de votre site ? Achille

Mécanismes d'authentification basés sur javascript, Java, ou ActiveX

Intérêt ?

Vous avez un site Web qui contient une partie authentification (partie administration, espace membre, etc...) et vous assurez l'authentification via activeX, des classes Java ou pire javascript? ceci peut poser des failles de sécurité car le code source, ou tout du moins des informations sur les procédures que vous utilisez pour authentifier peut etre visible chez le client car des fichiers sont envoyés au client

Exemple ?

Quel est l'intérêt? Vols de mot de passe, de numéro de carte de crédit lors d'un paiement sur un site d'achat en ligne, les raisons sont vastes et variées.

Comment ?

Il suffit d'analyser le code de vos classes ou le code source de vos javascript pour comprendre comment se fait l'authentification; de ce fait, il est plus simple pour quelqu'un qui cherche à s'authentifier sur votre site comme administrateur ou à usurper l'identité de quelqu'un pour accéder à son espace membre.

Que faire ?

Pour empêcher ce type d'attaques, il faut que tout se passe du coté serveur, et que seules les données d'identifications soient du coté client; rien de tel qu'un script php pour ca :) Java le permet aussi, lorsque tout est executé du côté serveur :)

Complément

Faites une recherche sur google avec java decompiler class et vous comprendrez :)...

Cross site scripting

Intérêt ?

Le cross-site scripting - ou CSS - subit un énorme essort depuis quelques années, d'une part parce que ce type de failles est méconnu des developpeurs, et d'autre part par les temps de développements toujours restreints des applications. Il consiste en l'injection de script - Javascript, VBScript - dans des éléments dynamiques d'un serveur Web (php, cgi, etc...) . Elles permettent de s'attaquer aussi bien au client qu'au serveur. Prennons 2 exemples, l'un destiné au client, l'autre au serveur.

Exemple ?