RE: SSL fiabilité

トップ ページ

このメッセージに返信
著者: Ismael Touama
日付:  
To: guilde
題目: RE: SSL fiabilité
Oui tu parles tout simplement de contrôle au niveau
du serveur. Comme il existe un contrôle côté client
- n'en déplaise à ceux qui n'aime pas les sites
javascriptisés, mais un appel au serveur pour dire
que la date a été mal saisie ça gache des ressources
et ça fait impatienter l'internaute -.

Ceci dit, il me semble que les contrôles serveur sont très
rigoureux et nécessitent plus d'un backslash (chose que tu
dois savoir).
Personnellement je fais mes 'remplacements de caractères spéciaux
avant d'invoquer mon serveur de BD.

bbsc
ism

-----Message d'origine-----
De : Olivier_Allard-Jacquin@???
[mailto:Olivier_Allard-Jacquin@amat.com]
Envoyé : vendredi 12 juillet 2002 15:14
À : guilde@???
Objet : 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