Le site sur lequel je travaille permet aux utilisateurs de faire leurs
propres requêtes SQL SELECT, à la façon de MyAdmin. Oui, je sais,
c'est une faille de sécurité, et j'ai des doutes sur l'utilité de
cette page puisque le programme sera utilisé par des buses en
informatiques, mais bon, mon patron a dit que c'était une
fonctionnalité super extra géniale, et comme l'ordre hiérarchique
n'est pas en ma faveur, je n'ai qu'à répondre oui monsieur...
Pour (tenter de) sécuriser cette partie, j'ai créé un utilisateur
dédié, avec que des droits SELECT, etc...
Je souhaite également parser cette requete pour isoler les mots clefs
(WHERE, FROM, GROUP BY, AS...), la mise en forme des résultats
n'étant pas la même sur des requetes statistiques (avec GROUP BY) que
sur des SELECT ... WHERE ...
J'ai cherché, et n'ai trouvé aucune expression régulière qui ne se
perde pas dans des guillemets, etc...
Quelle expression régulière utiliseriez vous pour gérer "select nom
as ' group by ' from table t where truc = 'having' " ?
On pourrait très bien imaginer un '[a-zA-Z0-9(\\')]*' mais ça
nécéssiterait d'être EXHAUSTIF vis à vis des accents, etc...
MySQL fait bien ça, mais comme je suis jamais rentré dans leur code
source, il me faudrait 3 jours rien que pour "m'approprier" leur façon
de programmer...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric
"MySQL fait bien ça, mais comme je suis jamais rentré dans leur code source, il me faudrait 3 jours rien que pour "m'approprier" leur façon de programmer... "
Vous aurez bien évidemment tous lu PhpMyAdmin
"MySQL fait bien ça, mais comme je suis jamais rentré dans leur code
source, il me faudrait 3 jours rien que pour "m'approprier" leur façon
de programmer... "
"MySQL fait bien ça, mais comme je suis jamais rentré dans leur code source, il me faudrait 3 jours rien que pour "m'approprier" leur façon de programmer... "
Vous aurez bien évidemment tous lu PhpMyAdmin
Laurent
Eric wrote:
Je souhaite également parser cette requete pour isoler les mots clefs (WHERE, FROM, GROUP BY, AS...), la mise en forme des résultats n'étant pas la même sur des requetes statistiques (avec GROUP BY) que sur des SELECT ... WHERE ...
J'ai cherché, et n'ai trouvé aucune expression régulière qui ne se perde pas dans des guillemets, etc...
Je suis un peu dans la même situation, et j'ai commencé à faire un "moteur de règles" ou l'utilisateur n'a pas vraiment le choix et où il est guidé, et où il choisit avec des listbox ou des textbox
exemple (ce que je viens de dire est assez flou je l'admet :)) listbox : afficher/effacer listbox : les garcons/les filles/tous "qui ont" listbox : plus, moins "de" textbox où on rentre un chiffre "ans"
ca donne donc par exemple : afficher les garcons qui ont moins de 30 ans.
C'est une idée, hein...
Eric wrote:
Je souhaite également parser cette requete pour isoler les mots clefs
(WHERE, FROM, GROUP BY, AS...), la mise en forme des résultats
n'étant pas la même sur des requetes statistiques (avec GROUP BY) que
sur des SELECT ... WHERE ...
J'ai cherché, et n'ai trouvé aucune expression régulière qui ne se
perde pas dans des guillemets, etc...
Je suis un peu dans la même situation, et j'ai commencé à faire un
"moteur de règles" ou l'utilisateur n'a pas vraiment le choix et où il
est guidé, et où il choisit avec des listbox ou des textbox
exemple (ce que je viens de dire est assez flou je l'admet :))
listbox : afficher/effacer
listbox : les garcons/les filles/tous
"qui ont"
listbox : plus, moins
"de"
textbox où on rentre un chiffre
"ans"
ca donne donc par exemple : afficher les garcons qui ont moins de 30 ans.
Je souhaite également parser cette requete pour isoler les mots clefs (WHERE, FROM, GROUP BY, AS...), la mise en forme des résultats n'étant pas la même sur des requetes statistiques (avec GROUP BY) que sur des SELECT ... WHERE ...
J'ai cherché, et n'ai trouvé aucune expression régulière qui ne se perde pas dans des guillemets, etc...
Je suis un peu dans la même situation, et j'ai commencé à faire un "moteur de règles" ou l'utilisateur n'a pas vraiment le choix et où il est guidé, et où il choisit avec des listbox ou des textbox
exemple (ce que je viens de dire est assez flou je l'admet :)) listbox : afficher/effacer listbox : les garcons/les filles/tous "qui ont" listbox : plus, moins "de" textbox où on rentre un chiffre "ans"
ca donne donc par exemple : afficher les garcons qui ont moins de 30 ans.
C'est une idée, hein...
Eric
Je suis un peu dans la même situation, et j'ai commencé à faire un "moteur de règles" ou l'utilisateur n'a pas vraiment le choix et où il est guidé, et où il choisit avec des listbox ou des textbox
C'est effectivement la technique utilisée dans la version actuelle (opérationelle mais pas sure en termes de fiabilité.) L'utilisateur choisit les champs à afficher, leur ordre toussa. A la fin, on lui présente une zone de texte où il peut affiner la requête avec des fonctionnalités non prises en charge par le logiciel (comme les fonctions statistiques/group by). Cette page est au point (à un ou deux addslashes et htmlentities près, rien de bien compliqué...), passons à la deuxième page, elle reçoit en paramètre la requete, et l'exécute. J'aimerais qu'elle [la page] vérifie un certain nombre de critère dessus [la requete] : utilise-t-elle des fontions statistiques, des group by ? sur quelle(s) table(s) d'exécute la requete ?
Bref, le problème n'est pas de générer la requete, mais de l'exécuter en toute sécurité.
La première page est classique : JE fais les requetes, après vérification des paramètres fournis par l'utilisateur. Dans la deuxième page, je donne les rennes à l'utilisateur, et il ne serait pas tout à fait de mon gout qu'il aille droit dans le mur (intensionellment ou pas) avec !
Je suis un peu dans la même situation, et j'ai commencé à faire un
"moteur de règles" ou l'utilisateur n'a pas vraiment le choix et où il
est guidé, et où il choisit avec des listbox ou des textbox
C'est effectivement la technique utilisée dans la version actuelle
(opérationelle mais pas sure en termes de fiabilité.)
L'utilisateur choisit les champs à afficher, leur ordre toussa. A la
fin, on lui présente une zone de texte où il peut affiner la requête
avec des fonctionnalités non prises en charge par le logiciel (comme
les fonctions statistiques/group by).
Cette page est au point (à un ou deux addslashes et htmlentities
près, rien de bien compliqué...), passons à la deuxième page, elle
reçoit en paramètre la requete, et l'exécute.
J'aimerais qu'elle [la page] vérifie un certain nombre de critère
dessus [la requete] : utilise-t-elle des fontions statistiques, des
group by ? sur quelle(s) table(s) d'exécute la requete ?
Bref, le problème n'est pas de générer la requete, mais de
l'exécuter en toute sécurité.
La première page est classique : JE fais les requetes, après
vérification des paramètres fournis par l'utilisateur.
Dans la deuxième page, je donne les rennes à l'utilisateur, et il ne
serait pas tout à fait de mon gout qu'il aille droit dans le mur
(intensionellment ou pas) avec !
Je suis un peu dans la même situation, et j'ai commencé à faire un "moteur de règles" ou l'utilisateur n'a pas vraiment le choix et où il est guidé, et où il choisit avec des listbox ou des textbox
C'est effectivement la technique utilisée dans la version actuelle (opérationelle mais pas sure en termes de fiabilité.) L'utilisateur choisit les champs à afficher, leur ordre toussa. A la fin, on lui présente une zone de texte où il peut affiner la requête avec des fonctionnalités non prises en charge par le logiciel (comme les fonctions statistiques/group by). Cette page est au point (à un ou deux addslashes et htmlentities près, rien de bien compliqué...), passons à la deuxième page, elle reçoit en paramètre la requete, et l'exécute. J'aimerais qu'elle [la page] vérifie un certain nombre de critère dessus [la requete] : utilise-t-elle des fontions statistiques, des group by ? sur quelle(s) table(s) d'exécute la requete ?
Bref, le problème n'est pas de générer la requete, mais de l'exécuter en toute sécurité.
La première page est classique : JE fais les requetes, après vérification des paramètres fournis par l'utilisateur. Dans la deuxième page, je donne les rennes à l'utilisateur, et il ne serait pas tout à fait de mon gout qu'il aille droit dans le mur (intensionellment ou pas) avec !
Vincent Lascaux
Quelle expression régulière utiliseriez vous pour gérer "select nom as ' group by ' from table t where truc = 'having' " ?
A mon avis c'est utopique de vouloir le faire en une étape, avec une seule expression réguliere. Peut être qu'on peut, mais moi je m'y risquerais pas... Si je devais me lancer là dedans, je regarderais s'il existe pas un lex / yacc pour PHP, et je chercherai la grammaire des requêtes SQL.
A mon avis tu devrais présenter à ton patron les problemes que ca souleve et suggérer que si c'est fait nul par ailleurs, c'est que c'est pas gérable... D'un point de vue sécurité, c'est impensable, pour l'utilisateur c'est pas vraiment ergonomique.
Bref, je suis d'accord avec Laurent : se fixer des limites (quelle est la complexité des requêtes qu'on veut permettre : est ce qu'on veut permettre des jointures par exemple ? est ce qu'on veut laisser l'utilisateur travailler sur plusieurs tables ? Qu'est ce qu'il va se passer si l'utilisateur entre une requête qui prend 5 ans à être réalisée, en prenant 100% du CPU pendant tout le temps d'execution ?...), ensuite penser à un systeme ergonomique qui permet de faire la plus grande partie des requetes dans les limites qu'on s'est fixées et enfin implémenter ca. Ca sera toujours des tonnes de travaille en moins que tenter de sécuriser un truc où la feature c'est "je laisse l'utilisateur faire ce qu'il veut avec la machine"...
-- Vincent
Quelle expression régulière utiliseriez vous pour gérer "select nom
as ' group by ' from table t where truc = 'having' " ?
A mon avis c'est utopique de vouloir le faire en une étape, avec une seule
expression réguliere. Peut être qu'on peut, mais moi je m'y risquerais
pas...
Si je devais me lancer là dedans, je regarderais s'il existe pas un lex /
yacc pour PHP, et je chercherai la grammaire des requêtes SQL.
A mon avis tu devrais présenter à ton patron les problemes que ca souleve et
suggérer que si c'est fait nul par ailleurs, c'est que c'est pas gérable...
D'un point de vue sécurité, c'est impensable, pour l'utilisateur c'est pas
vraiment ergonomique.
Bref, je suis d'accord avec Laurent : se fixer des limites (quelle est la
complexité des requêtes qu'on veut permettre : est ce qu'on veut permettre
des jointures par exemple ? est ce qu'on veut laisser l'utilisateur
travailler sur plusieurs tables ? Qu'est ce qu'il va se passer si
l'utilisateur entre une requête qui prend 5 ans à être réalisée, en prenant
100% du CPU pendant tout le temps d'execution ?...), ensuite penser à un
systeme ergonomique qui permet de faire la plus grande partie des requetes
dans les limites qu'on s'est fixées et enfin implémenter ca. Ca sera
toujours des tonnes de travaille en moins que tenter de sécuriser un truc où
la feature c'est "je laisse l'utilisateur faire ce qu'il veut avec la
machine"...
Quelle expression régulière utiliseriez vous pour gérer "select nom as ' group by ' from table t where truc = 'having' " ?
A mon avis c'est utopique de vouloir le faire en une étape, avec une seule expression réguliere. Peut être qu'on peut, mais moi je m'y risquerais pas... Si je devais me lancer là dedans, je regarderais s'il existe pas un lex / yacc pour PHP, et je chercherai la grammaire des requêtes SQL.
A mon avis tu devrais présenter à ton patron les problemes que ca souleve et suggérer que si c'est fait nul par ailleurs, c'est que c'est pas gérable... D'un point de vue sécurité, c'est impensable, pour l'utilisateur c'est pas vraiment ergonomique.
Bref, je suis d'accord avec Laurent : se fixer des limites (quelle est la complexité des requêtes qu'on veut permettre : est ce qu'on veut permettre des jointures par exemple ? est ce qu'on veut laisser l'utilisateur travailler sur plusieurs tables ? Qu'est ce qu'il va se passer si l'utilisateur entre une requête qui prend 5 ans à être réalisée, en prenant 100% du CPU pendant tout le temps d'execution ?...), ensuite penser à un systeme ergonomique qui permet de faire la plus grande partie des requetes dans les limites qu'on s'est fixées et enfin implémenter ca. Ca sera toujours des tonnes de travaille en moins que tenter de sécuriser un truc où la feature c'est "je laisse l'utilisateur faire ce qu'il veut avec la machine"...
