| |
| Voir le sujet précédent :: Voir le sujet suivant |
| Auteur |
Message |
tsiry

Inscrit le: 12 Déc 2006 Messages: 5
|
Posté le: Mar Déc 12, 2006 9:08 pm Sujet du message: Sécuriser la session utilisateur (Injection SQL) |
|
|
Les applications web utilisant les clients légers que sont les navigateurs web protègent leurs utilisateurs par la création de sessions. Ces sessions sont des espaces de travail dans le temps disposant d'un espace de stockage d'informations. Cet espace de travail est privé et est propre à un utilisateur particulier dûment authentifié.
Ces sessions sont un système de protection efficace lorsque correctement employé par le développeur de l'application web. Cependant, il est courant de constater des carences dans la sûreté d'emploi des sessions. Ainsi, les sessions peuvent devenir un élément d'insécurité et venir rompre la chaîne de sécurité du système d'information sur lequel repose l'application.
Il convient de respecter certaines bonnes pratiques dans l'usage des sessions.
SQL INJECTIONS
L'attaque par SQL injection, ou plus généralement par commande injection consiste à injecter du code malveillant, en l'occurrence une requête SQL dans un paramètre. Si ce paramètre est insuffisamment contrôlé par l'application et est utilisé au sein d'une commande système, où d'une requête de base de données, alors cette dernière va voir son comportement modifié : des actions non prévues vont être pilotées à distance par un pirate. Les conséquences d'une telle attaque peuvent être la corruption de données et la prise d'accès frauduleux sur le serveur.
Exemple de code PHP/MySQL vulnérable à une SQL injection
<?php
mysql_query("SELECT * FROM utilisateurs WHERE login='$login'");
?>
Code SQL injecté
toto'; DROP TABLE utilisateurs; #
Requête SQL exécutée par l'application
SELECT * FROM utilisateurs WHERE login='toto'; DROP TABLE utilisateurs; #'
Et voici les requêtes qui renvoient toujours 'vrai' :
SELECT * FROM table WHERE 1=1
SELECT * FROM table WHERE 'uuu'='uuu'
SELECT * FROM table WHERE 1<>2
SELECT * FROM table WHERE 3>2
SELECT * FROM table WHERE 2<3
SELECT * FROM table WHERE 1
SELECT * FROM table WHERE 1+1
SELECT * FROM table WHERE 1--1
SELECT * FROM table WHERE ISNULL(NULL)
SELECT * FROM table WHERE ISNULL(COT(0))
SELECT * FROM table WHERE 1 IS NOT NULL
SELECT * FROM table WHERE NULL IS NULL
SELECT * FROM table WHERE 2 BETWEEN 1 AND 3
SELECT * FROM table WHERE 'b' BETWEEN 'a' AND 'c'
SELECT * FROM table WHERE 2 IN (0,1,2)
SELECT * FROM table WHERE CASE WHEN 1>0 THEN 1 END
On affirme à chaque fois une réalité sûre : 1=1 (1 égal 1... hé oui), 1 est different de 2, 3 est plus grand que 2, b se trouve entre a et c, NULL est NULL, etc... Il en existe bien sûr bien d'autres.
Cette idée d'expression qui renvoie toujours 'vrai' est un des grands principes de l'injection SQL.
En effet, si on arrive à insérer un "toujours vrai" dans la requête, inutile d'avoir un login et un mot de passe.
Par exemple en donnant à $login et $pass la valeur : ' OR 'a'='a, on executera une requête SQL du type :
SELECT id FROM utilisateur WHERE login='' OR 'a'='a' AND password='' OR 'a'='a'
Ce qui renverra 'vrai', puisque 'a'='a' est toujours vrai !
Si on veut pouvoir choisir le compte auquel accèder, il faut avoir une information, par exemple le pseudo.
Si on veut accéder au compte de Marc, il suffit de rentrer comme $login "marc" et comme $pass une expression renvoyant toujours 'vrai', par exemple : ' OR 'b' BETWEEN 'a' AND 'c, ce qui executera la requête :
SELECT id FROM utilisateur WHERE login='marc' AND password='' OR 'b' BETWEEN 'a' AND 'c'
SOLUTIONS
L'utilisation du protocole HTTPS au lieu de HTTP permet de se prémunir contre les sondes réseau sniffant le trafic entre client et serveur. En effet le protocole SSL encapsule HTTP afin d'authentifier le client et de chiffrer les données échangées, assurant ainsi la confidentialité des échanges.
Afin de se prémunir contre l'utilisation de la session d'un utilisateur quittant un cybercafé en oubliant fermer le navigateur par une personne malhonnête venant à la suite, il est utile de ne pas donner pour durée de vie à la session la vie de la fenêtre du navigateur. Fermer d'office la session après une duré d'inactivité de 15 minutes est raisonnable.
Fournir à l'utilisateur ou moyen de se déconnecter dès ses tâches terminées permet de réduire l'exploitation de son cookie de session par un pirate ayant écouté le réseau. Ainsi, un bouton où un lien "se déconnecter" permet d'écourter une session.
CONCLUSION
La sécurité de la session dépend de plusieurs acteurs : l'équipe de développement de l'application web, mais aussi du gestionnaire de session employé ainsi que de l'utilisateur qui doit être mis en garde contre l'usage de son navigateur par d'autres personnes. Des solutions simples permettent d'éviter la plupart des cas possibles de compromission de la session de l'utilisateur. |
|
| Revenir en haut de page |
|
 |
kiambala
Inscrit le: 26 Déc 2006 Messages: 2
|
Posté le: Mar Déc 26, 2006 10:23 pm Sujet du message: autre solution pour éviter les injections Sql |
|
|
On peut aussi utiliser un fichier .htaccess avec le libapache-mod-auth-mysql si on ne peut pas s'offrir un https://
vous trouverez ici la configuration
http://modauthmysql.sourceforge.net/CONFIGURE |
|
| Revenir en haut de page |
|
 |
|
|
Vous ne pouvez pas poster de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas voter dans les sondages de ce forum
|
| |
|