RE: SSL fiabilité

Top Page

Reply to this message
Author: Olivier_Allard-Jacquin
Date:  
To: guilde
Subject: RE: SSL fiabilité


      Ce n'est pas l'utilisation du langage (ASP, PHP, CGI-BIN, etc ...)
que je critique (quoiqu'ayant programmé avec ces 3 la, j'ai une idée assez
précise lequel est le pire ...)


      C'est la manière dont le developpeur à codé ses requêtes à sa
base de données que je met en doute ...


      Un exemple tout simple, trop sans doute, mais qui est assez
marquant: Je crois l'avoir déjà donnée, pour ceux qui le connaissent
ne m'en veuillez pas trop:


- Une page HTML avec un champ où l'utilisateur doit rentrer son nom:
      <INPUT name="UserName" type="text"></INPUT>


- Sur un serveur, une base de données contenant une table "UserData"
avec 3 champs: "UserName" "Adress" et "CreditCardNumber"

- Sur le serveur web, une page dynamique (je prend le PHP en exemple,
mais c'est valable pour toutes les techniques de web dynamique) qui
récupère cette info et crée une requête pour la base de données:

QueryString= "SELECT Adress, CreditCardNumber FROM UserData WHERE UserName
= " . UserName

      Si un utilisateur rentre son mon, cette requete retournera son
adresse et son numero de carte de crédit.



      Maintenant, prenons un utilisateur quelconque qui au lieu de taper
son nom mettra dans le champ "UserName" ceci;


"; SELECT * FROM UserData"

Petit rappel: en SQL, le ";" est un séparateur de commande; Comme le ";"
en shell

      La base de donnée va donc executer 2 requêtes coup sur coup:
SELECT Adress, CreditCardNumber FROM UserData WHERE UserName =
SELECT * FROM UserData


ce qui pourra afficher la liste de TOUT les utilisateurs, ainsi que de leur
adresse
et carte de crédit ... Evidement, cela va dépendre de la manière donc est
ecrit le
code qui va afficher la page HTML, mais avec quelques essais, on peut
arriver
à un bon résultat

      Plus violent encore. L'utilisateur tape:
"; DROP TABLE UserData"


Si l'utilisateur qui execute cette requête à les droits nécéssaire pour
supprimer
la table (2nd GROSSE erreur de la part du developpeur), celle-ci sera
detruite,
et toutes les précieuses informations clientes avec ...

      Pourtant, il existe un moyen TRES simple d'éviter un tel problème.
Il suffit de créer une fonction qui va "backslasher" tous les caractères
spéciaux
du SQL, et d'appliquer cette fonction à tout les paramètres lors de la
création de la commande SQL:


QueryString= "SELECT Adress, CreditCardNumber FROM UserData WHERE UserName
= " . Backslash_SQL_String(UserName)

      Voila, c'est tout simple, mais ce n'est pas rare qu'un
developpeur de site dynamique n'y pense pas. C'est pour cela
je parle de "petits rigolos". Et dans ce cas, le
site devient une vrai passoire, et tout les firewall du monde n'y
ferons rien ...


      Encore une fois, ce n'est pas le langage que je critique,
mais la mauvaise utilisation de celui-ci. C'est comme le C. En lui
même, le langage n'est pas mauvais. Par contre, une mauvaise
utilisation de fonctions comme "gets" peut ammener à des trous
de sécurité de type "buffer overflow" ...


                                    Olivier



> > Quand on voit comment certains petits rigolos
> > codent
> > leur ASP, PHP, CGI-BIN pour accéder à leur base de données,

franchement, ca
> > fait
> > peur ...
> >
> Justement, comment le coderais-tu ? (ASP, PHP, CGI-BIN)
> ism