Discussion :

[JackBeauregard]

Bonjour,

Je viens de penser à un petit (gros ?) trou de sécurité dans le forum que j'ai programmé.
J'ai des liens comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
http://www.site.com/sujet-choix.php?affichage=1&debut=10

ici ?debut=10 c'est le nombre de tuples à aller chercher. C'est une variable dont la valeur sert de paramètre à la requête sql.
Si on entre quoi que ce soit d'autre qu'un chiffre, la requête génère l'erreur suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home.2/site/scripts/compte/compte/sujet-choix.php on line 82
 
Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /home.2/site/scripts/compte/compte/sujet-choix.php on line 135

Bien sûr je filtre la variable $_GET[debut] par htmlspecialchars et mysql_real_escape_string.
Mais tout de même, je pense que le fait d'afficher ces erreurs est mauvais pour la sécurité, ne serait-ce que parce que cela donne des informations sur le serveur (même si pour le moment c'est un mutualisé).


Une solution consiste donc à n'exécuter la requête que si le masque est corrrect, sinon on ne fait rien.
Dans les autres pages je n'ai pas ce problème car il y a un url rewriting qui génère une page d'erreur.

Voilà, qu'en pensez-vous ? Je fais un preg_replace pour tester le masque de la variable ? Je le fais aussi sur les pages de l'url rewriting où c'est pas la peine sur celle-ci ?(j'ai déjà vu que yahoo affiche les pages avec des urls non rewritées).


Merci pour vos conseils (de pros si possible)

[Eusebius]

Bonjour
Juste un point de vue très général sur la question :

- phase de développement : on affiche TOUTES les erreurs, et on se débrouille pour qu'il n'en apparaisse plus aucune. Effectivement il faut faire attention à ce qu'on appelle l'injection SQL, le fait de mettre autre chose que ce qui est attendu dans une requête. Il faut donc toujours vérifier la cohérence des informations fournies par l'utilisateur (et éviter les exécutions de code externe).
- phase de production: on n'affiche plus les erreurs, mais par contre on reste conscient qu'il n'est plus censé en avoir, alors on les fait interpréter par le script, et on prévient un admin, un développeur... (envoi d'un mail, écriture dans un journal)

dans le php.ini, il y a une valeur display_errors qui pourra donc être mise à Off en production. On pourra aussi utiliser log_errors et les valeurs associées.
On vérifiera avec soin toutes les valeurs de retour.

On peut également configurer un gestionnaire d'erreurs personnalisé avec la fonction set_error_handler.

[JackBeauregard]

Je te remercie de ta réponse Eusébius.
Bon je reprend :

- phase de développement : on affiche TOUTES les erreurs, et on se débrouille pour qu'il n'en apparaisse plus aucune.

Ce n'est pas volontaire, je n'ai pas de mysql_error par exemple, simplement ça fait bugger le script, je ne peux rien y faire.

Effectivement il faut faire attention à ce qu'on appelle l'injection SQL, le fait de mettre autre chose que ce qui est attendu dans une requête.

mysql_real_escape_string doit supprimer les risques déjà (ou très fortement les réduire, y'a toujours des bêtes du piratage, mais bon....). Cela étant ce n'est pas une raison pour laisser s'afficher le message d'erreur dont j'ai parlé.

Il faut donc toujours vérifier la cohérence des informations fournies par l'utilisateur (et éviter les exécutions de code externe).

Le problème c'est que quand le champ est un input text qui peut recevoir n'importe quoi, on ne peut plus utiliser les expreg, il ne reste mysql_real_escape_string (ceci dit ce type de champ ne contiennent normalement pas de valeur passées en paramètre aux requêtes, donc pas de problème comme celui que je rencontre en ce moment).

- phase de production: on n'affiche plus les erreurs, mais par contre on reste conscient qu'il n'est plus censé en avoir, alors on les fait interpréter par le script, et on prévient un admin, un développeur... (envoi d'un mail, écriture dans un journal)

Comment faire pour être averti par mail ou par requête sql qu'une erreur vient de se déclencher dans la page ?

Pour le reste c'est du mutualisé je ne crois pas pouvoir modifier le php_ini.

[Eusebius]

Juste histoire de préciser, ce que j'ai dit n'était pas personnalisé : j'ai pas forcément dit que tu ne faisais pas ce que je conseillais.

Ce n'est pas volontaire, je n'ai pas de mysql_error par exemple, simplement ça fait bugger le script, je ne peux rien y faire.

Tu fais tes requêtes comme précisé dans ma signature ?

Le problème c'est que quand le champ est un input text qui peut recevoir n'importe quoi, on ne peut plus utiliser les expreg, il ne reste mysql_real_escape_string (ceci dit ce type de champ ne contiennent normalement pas de valeur passées en paramètre aux requêtes, donc pas de problème comme celui que je rencontre en ce moment).

Si tu as des spécifications précises, tu dois pouvoir définir un certains nombre de critères pour chaque entrée, qui limitent déjà les possibilités d'erreur (i.e. c'est un nombre, il est compris entre tant est tant, il n'y a pas tel ou tel caractère...)

Comment faire pour être averti par mail ou par requête sql qu'une erreur vient de se déclencher dans la page ?

Avec set_error_handler, tu peux spécifier une fonction à appeler en cas d'erreur. Cette fonction, c'est toi qui l'écris donc tu en fais ce que tu veux ! C'est très intéressant comme procédé.

[JackBeauregard]

Tu fais tes requêtes comme précisé dans ma signature ?

Non je n'utilise pas die et mysql_error() sauf si j'ai une erreur quand je programme et encore en général j'y pense pas (j'ai peur d'oublier de l'enlever).
Dans le cas présent, la requête fonctionne bien, elle attend simplement un nombre et si on entre autre chose dans l'url (ce que l'on est pas censé faire...), alors ça fait bugger le script.
Je filtre l'entré, mais tout de même je crois que je vais faire un preg_replace() pour supprimer cette erreur.

Si tu as des spécifications précises, tu dois pouvoir définir un certains nombre de critères pour chaque entrée, qui limitent déjà les possibilités d'erreur (i.e. c'est un nombre, il est compris entre tant est tant, il n'y a pas tel ou tel caractère...)

Je me demande si c'est vraiment la peine pour l'intégralité des formulaires.
Par exemple, j'ai un script qui réagit si $_POST['var']==1.
Je filtre la variable htmlentities(mysql_real_escape_string()) de toute façon. Mais si $_POST['var'] n'est pas égal à 1 ça ne fera rien c'est tout, la valeur n'est pas passée en paramètre à une variable contrairement au cas que j'ai expliqué au début.
Et si le gars m'envoit une injonction sql, elle atterira dans la base, mais cassée par mysql_real_escape_string().

Avec set_error_handler, tu peux spécifier une fonction à appeler en cas d'erreur.

Ok, je connaissais pas cette fonction, merci de me la faire découvrir. ça m'a pas l'air évident à utiliser, mais quand je serai dessus je posterai à propos si nécessaire.

[berceker united]

Dans mes developpement, j'aime controler ce que je donne à manger à ma base car il lui faut lui donner de la nourriture saine .
Là ou il attend une valeur numérique il y aura une une valeur numérique garantie. De plus je m'assure que cette valeur existe bien dans la base de données. Si c'est pas le cas c'est que quelqu'un s'amuse à changer les valeurs pour provoquer quelque chose.
Je fais en sorte limiter le maximum d'information passé en url ou champs caché. Je compte sur l'intégrité et la justesse des informations déjà présente.
L'entrée et la sortie de ma base de données passe toujours par un objet via les accesseurs correspondant ainsi les variables sont typé (façon de voir); Exemple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Class Toto{
    private $id;
 
   public Function setId($pId){
      $this->id = (integer) $pId;
    }
 
  public Function getId(){
    return (integer) $this->id;
  }
 
}