Discussion :

[FadeToBlack]

Bonjour à tous,

J'aimerais entamer une petite discussion concernant la sécurité dans la gestion des données entre un quelconque serveur Sql et Php.

Mon prof n'a jamais cessé de nous transmettre sa paranoïa concernant l'interrogation d'une base de donnée par php. Son mot d'ordre était toujours de dire que Sql ne devait faire confiance à personne et en toutes circonstances.

Maintenant, je me pose la question de savoir comment orienter des requêtes préparées (via PDO) avec l'existence d'une (de) procédure(s) stockée(s).

Et puis surtout cela sert-il à quelque chose d'écrire un truc du genre*?:

Code :

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

1
2
3
4
5
$req = $connex->prepare('call ps_insertFoo(IN var1, IN Var2,etc...., OUT result etc....)')*;
$req->bindParam(':var1',*$var1,*PDO::PARAM_INT);
$req->bindParam(':var2',*$var2, PDO::PARAM_STR); 
etc....
$req->execute()*;

En terme de sécurité, personnellement je passe par plusieurs phases*:
1) verification des formulaires via Jquery et de temps en temps Ajax
2) Comme javascript peut être arrêté, une autre vérification lors de l'arrivée des données dans le constructeur de mes classes. J'ai construit une classe Verif avec plein de tests en tous genres.
3) Envoi des données à Mysql en passant par une procédure stockée. Cette (ces) PS, refont un test des valeurs avant d'exécuter la(les) requete(s)

Avez vous un avis sur la question*et surtout ou avez-vous placé le curseur de votre paranoïa*?

Bonne journée à tous

[Exia_]

Bonjour,

pas compris le coup du *, après ton prof a raison et pas seulement en PHP,

le SQL ne doit faire confiance en AUCUN langage quel qu'il soit,

l'utilisation de la méthode prepare de PHP est une aide à la sécurisation des données donné au SQL.

[FadeToBlack]

Salut,

effectivement, le "*" est en trop. faute de frappes et usage intempestif du copie/coller

Je comprends bien que les requêtes préparées servent ou aident à la sécurisation des données envoyées au SQL. Mais est-ce utile si des vérifications ont été faite avant et au moment de la création des objets sous php.

En termes clairs, n'y a-t-il pas une limite objective à la paranoïa.?

il ya :
- contrôle javascript
- contrôle à la création des objets
- contrôle dans les requêtes préparées
- contrôle dans les procédures stockées et transactions

[Exia_]

Le controle Javascript n'est pas tellement un controle pour moi car facilement désactivable,

ensuite quand tu dit :

- contrôle dans les procédures stockées et transactions

tu parle de quel controle ? Qu'un chaîne de caractère ne tente pas de faire une injection SQL ou qu'un nouveau membre ne tente pas de s'inscrire avec un pseudo déjà utilisé ?

[k'amm]

Bonjour FadeToBlack,

Je pense que trop de sécurité n'est jamais superflu et je filtre personnellement mes données à trois niveaux :
- en JS lors du remplissage des champs (principalement pour des raisons d'ergonomie, meilleure expérience utilisateur) ;
==> Je ne considère pas ça comme une sécurité puisqu'elle peut être facilement désactivée (un simple plugin, voir un paramètre de ton navigateur ou l'utilisation d'un navigateur texte type lynx suffit).
- en PHP au moment de la réception des données ;
==> Ma première véritable sécurité, principe de base : sécuriser tous les points d'entrées de ton application, donc filtrer toutes les données reçues du client (aussi bien pour éviter une faille de sécurité côté SQL que PHP !).
- en PHP juste avant insertion, au moment du binding des données.
==> comme sur tous les points d'entrées vers ma BDD, pour garantir l'intégrité de ma BDD.
Ne serait-ce que pour éviter qu'un autre utilise les méthodes d'insertion - ou de selection, ou de mise à jour d'ailleurs - avec des paramètres incorrects !

Le fait de toujours binder ces requêtes - outre le gain de temps dû au pré-calcul de la requête par le SGBD - ajoute une sécurité supplémentaire puisqu'il prévient d'une éventuelle injection SQL.

De là à utiliser des procédures stockées... ce serait un peu trop lourd à mon sens de faire une procédure stockée par requête (comme dans le cas d'une insertion, ou d'une sélection simple) mais les deux filtres que je mets sont le minimum à mon sens si tu ne veux pas avoir de surprises.
Autrement dit
=> sécuriser tous les points d'entrées à ton application
=> sécuriser tous les points d'entrées à ta BDD
...et roule !

Edit : ça poste vite par ici !
- contrôle javascript => ne voit vraiment pas ça comme un contrôle mais une aide pour l'utilisateur, rien de plus
Le minimum vital côté sécurité est ceci :
- contrôle à la création des objets
- contrôle dans les requêtes préparées

[FadeToBlack]

tu parle de quel controle ? Qu'un chaîne de caractère ne tente pas de faire une injection SQL ou qu'un nouveau membre ne tente pas de s'inscrire avec un pseudo déjà utilisé ?

En fait, les deux. La premières est évidemment là pour la sécurisation de ma base de données(son intégrité physique). La seconde pour éviter la fuite des données.

@ k'amm :
Je sais bien que javascript n'est pas du tout un méthode de sécurisation. Simplement et uniquement une aide, un premier filtre qui évite qu'un utilisateur étourdit envoie n'importe quoi au serveur Php. Et aussi pour construire un système à bonne ergonomie.

Donc tu n'utilises pas de PS dans tes bases ? Et quid de transactions au niveau de Php avec des commit() et des rollbacks ?

a+

[k'amm]

Donc tu n'utilises pas de PS dans tes bases ? Et quid de transactions au niveau de Php avec des commit() et des rollbacks ?

Plusieurs cas d'exemple :
- tu dois juste récupérer un certain nombre de lignes selon des paramètres données (moteur de recherche, tri sur un tableau, etc) ;
- tu dois insérer une ligne dans une table suite à une action (création d'un nouveau post sur un forum) ;
- tu dois insérer plusieurs lignes dans plusieurs tables suite à une action (création d'un nouvel utilisateur avec affectation d'un groupe, de droits spécifiques et d'informations concernant l'utilisateur)

Dans les deux premiers cas, une transaction n'est pas utile, pas plus qu'une procédure stockée, puisqu'il s'agit d'une seule requête.
Dans le troisième, il y a plusieurs opérations à faire, qui sont liées entre elles, une transaction est donc tout à fait justifiée (toutes les opérations passent, ou aucune) et une procédure stockée pourra être envisagée

[FadeToBlack]

Salut ABCIWEB et les autres

Ma question, à la base, était surtout une question théorique, sur vos propres habitudes. Je suis tout à fait conscient qu'une transaction pour un simple SELECT, même avec des jointures, n'est pas utile.

Je voulais prendre le cas général avec tous les moyens mis à notre dispositions pour protéger nos applications des pirates, bien évidemment, mais surtout des utilisateurs (souvent les plus dangereux en terme de pertes de temps).

Cela fait un certains temps que je développe des petites BDD et je m'aperçois tous les jours, même après une formation, que les utilisateurs arrivent à entrer des données qui ne devraient pas être saisie. Date de naissance en 2500... , des noms avec des chiffres etc.......

ABCIWEB : je vais lire le doc, cela m'intéresse beaucoup en effet.

[ABCIWEB]

Cela fait un certains temps que je développe des petites BDD et je m'aperçois tous les jours, même après une formation, que les utilisateurs arrivent à entrer des données qui ne devraient pas être saisie. Date de naissance en 2500... , des noms avec des chiffres etc.......

Oui mais dans ces cas il s'agit de validation des données. On pourrait facilement vérifier que la date saisie soit antérieure à la date actuelle ce qui éviterait d'entrer aujourd'hui des dates de naissances vers 2050 mais rien n'empêchera le visiteur de saisir une date qui n'est pas la sienne. En résumé il faut bien différencier les valeurs non valides (qu'on ne peut jamais totalement éviter) des valeurs potentiellement dangereuses.

[ABCIWEB]

Le fait de toujours binder ces requêtes - outre le gain de temps dû au pré-calcul de la requête par le SGBD - ajoute une sécurité supplémentaire puisqu'il prévient d'une éventuelle injection SQL.

Ok pour la sécurité par contre concernant la rapidité, la préparation d'une requête prend un peu de temps qui sera rentabilisé par la suite uniquement en cas de requête multiples (par exemple un update dans une boucle). Par contre pour une requête qui n'est exécutée qu'une fois dans le script, la requête préparée sera un peu moins rapide (dû au temps de préparation justement) qu'une requête classique.

Pour les requêtes simples, j'utilise pour ma part des requêtes "normales" quand je peux contrôler les variables externes rigoureusement, par exemple en castant les variables en nombres ou en les comparant à un tableau de valeurs acceptables. Et quand il s'agit d'une chaine de caractères, je blinde par sécurité.

Je pense qu'on a largement les moyens de sécuriser les requêtes contre les injections sql et à mon avis ce n'est plus le problème majeur actuellement. En d'autres termes, cela reste un problème majeur de part les conséquences que cela peut avoir, mais avec les moyens de protection à notre disposition cela ne devrait plus l'être et ce n'est certainement plus le vecteur le plus employé par les pirates aujourd'hui. Pour dire que ce ne doit pas être l'arbre qui cache la forêt car il y a dans d'autres points plus délicats à sécuriser. Un petit guide ici