GÉNÉRER UNE REQUETE SQL AVEC JAVASCRIPT

Signaler
Messages postés
240
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
6 janvier 2006
-
Messages postés
4
Date d'inscription
jeudi 20 mai 2010
Statut
Membre
Dernière intervention
30 juin 2010
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/32766-generer-une-requete-sql-avec-javascript

Messages postés
4
Date d'inscription
jeudi 20 mai 2010
Statut
Membre
Dernière intervention
30 juin 2010

on peut imaginer que le pattern du statement SQL soit vérifié par la page de traitement.
on peut aussi limiter le GRANT aux champs de la table que l'on permet de selectionner.
Enfin j'essaye pas de faire approuver cette façon de générer le Statement.
Juste de considérer la faisabilité dans un environnement sécurisé.
Messages postés
12
Date d'inscription
mercredi 10 décembre 2003
Statut
Membre
Dernière intervention
28 octobre 2006

Je constate que ce code que j'avais posté il y'a 5 ans nourri encore de vives commentaires.
Il faut le remettre dans le contexte de l'époque, où j'étais un jeune étudiant fraichement sorti de l'école, qui s'essayais à toutes les technologies et avec une grande envie de bien faire.

Sans rentrer dans les détails techniques, je déconseille ce code, pour les raisons suivantes :
- le code javascript s'exécute du côté du client
- n'importe qui peut lire son contenu en affichant juste le code source de la page
- les requêtes sql écrites donnent des informations sur la structure de la base données (nom de table)
- les requêtes peuvent être modifiées par n'importe qui car pour récupérer ces données et les traiter sur le formulaire, on peut manipuler la valeur du paramètres "action" sur une page tierce
- la gestion des privilèges n'est souvent pas du ressort du développeur (et souvent l'administrateur de la base de données donne accès en insert,update, et très souvent delete)

Sur le plan syntaxique ce code est utile pour ceux qui veulent savoir comment :
- tester des chaines de caractères,
- concaténer des données récupérer des valeurs de champs de formulaires.

Mais sur le principe décrit ci-haut(construction d'une requête sql), il est mauvais.

Aussi, il est très difficile d'utiliser javascript pour interagir avec une base de données directement sans passer par un serveur d'application (apache, IIS, etc ...)
Et tous ces serveurs disposent de moteur de script (php, asp, asp.net) qui peuvent construire des requêtes sans que cela ne s'exécute côté client.

Et je conseille vivement de manipuler les requêtes du côté du serveur, ou au mieux de le gérer dans la base de données à l'aide de procédures stockées ou packages.
Messages postés
240
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
6 janvier 2006

Bonjour tout le monde

Quel plaisir de voir que des posts vieux comme le monde vivent encore :)
Ca fait bien longtemps que j'avais pas mis les pieds par ici et à force d'être harcelé de mails, ma curiosité m'a poussé à venir voir ce qui déchainait autant les passions sur ce post.

Je suis à l'origine du mot "dangereux". Le but n'est pas de remettre de l'huile sur le feu mais je pense qu'il faut insister sur quelques détails. Je ne suis pas là pour faire des querelles de voisinage, je n'ai rien à prouver à personne et mon message sera courtois.

Si on prend la chose comme un "proof of concept", en effet ça peut-être intéressant .... quoique très limité quand même :D
La principale chose à retenir, et la base de mon message il y a 5 ans, c'est que beaucoup de débutants perdus tombent sur ce genre de code. Certains d'ailleurs dans les coms le trouvent "merveilleux" ou encore "très utile". Autant dire une aberration venant personnes inexpérimentés ! Et c'est là où ça en devient dangereux. Un débutant n'aura pas idée de protéger l'accès par un utilisateur en lecture seule. Et quand bien même, je n'adhère absolument pas sur le fait que l'on puisse considérer ce code comme utilisable ... encore plus sous prétexte que "ça marche" !
Même avec un user en read only, un pirate pourrait en effet récupérer plus de champs que nécessaire sur la table par un bon select *...
Et tel quel par un copier-coller de source sans comprendre (comme ça arrive malheureusement trop souvent), ça représenterait une très très grosse faille de sécurité.

Et c'est que là qu'il est primordial que les gens qui lisent ce code se rendent compte que c'est une vraie passoire sur le plan sécurité. Beaucoup de personnes ici ne savent même pas que la notion d'utilisateurs existe dans MySQL.
La personne qui a posté le source aurait du indiqué cet avertissement ou les précautions d'usage ! C'est donc à nous, personnes expérimentés de la communauté, de les alerter sur les risques qu'ils encourent.

Au final pour clôturer :
Ce genre de code est vivement déconseillé pour un site web en production. C'est plutôt un bon exemple d'une mauvaise idée de construction de requêtes côté client.
Si vous souhaitez l'utiliser, pensez à :
- créer un utilisateur en lecture seule pour éviter une altération des données (http://dev.mysql.com/doc/refman/5.0/fr/user-account-management.html)
- donner les droits d'accès uniquement sur des vues (pour lesquelles vous aurez au préalable restreint la quantité de données, c'est-à-dire de colonnes, accessibles dans la requête)

Sur ce, bonne continuation à tous
Messages postés
4
Date d'inscription
jeudi 20 mai 2010
Statut
Membre
Dernière intervention
30 juin 2010

ce genre de chose oui :D

Et pour tout te dire et je continue à le dire, son code n'a rien de dangereux.
Tout simplement parceque sa requête SELECT peut être faite via un utilisateur readonly.

Même si c'est pas une méthode habituelle de générer son SQL statement dans le Javascript, son code n'a rien de dangereux en soit.

Et j'avoue que c'est ton commentaire sur l'algorithme qui m'a fait tiquer parce que je trouvais ça tout à fait inutile. Et comme tu peux t'en rendre compte, le niveau est indiqué en haut de la page.

Maintenant c'est sur que celà n'est pas recommandé mais du point de vue CONCEPT, comme tu dis, Je ne suis justement pas de l'avis général de dire que son code est dangereux.
Afficher les 20 commentaires