Requete spéciale SQL

cloacking · 15 Juin 2005

Bonsoir,
Je cherche à faire un truc spécial (du moins pour moi) ....

Grâce à la réecriture d'url j'ai dans un repertoire
/ref
une seule et unique page
index.php

J'ai fait en sorte que si on tape
bidule.html
truc.html
ça redirige automatiquement sur cette page.

La page concerné est en fait un template qui affiche des données sur les utilisateurs.
Sur mon site, on trouve des liens vers l'utilisateur grâce à son id
exemple :
tom (2)
maurice (3)
ou le 2 et 3 sont des liens vers
ref/2.html
ref/3.html

Ca m'affiche donc ma page ref/index.php
Jusque là tout va bien ....

Dans cette page, je voudrais faire une requete qui affiche les infos perso de l'utilisateur.
Ma table se nomme
porte
et je voudrais afficher les champs
enter et adresse

Le problème et que si je fais un select
SELECT * FROM `porte`

ça m'affiche toute les données et pas les données individuelle ....

J'espère que vous m'aurez compris car je m'exprime assez mal quand il s'agit de parler prog.

Merci

jeroen · 15 Juin 2005

Code:

 SELECT enter,adresse FROM porte WHERE id=$id

:?:

dh · 15 Juin 2005

slt

l'id du visiteur tu l'a passé dans l'url?
si oui recupere le sinon faut le passer
dh

cloacking · 15 Juin 2005

Je vais tester la première méthode mais je suis curieux de savoir comment je pourrais passer l'id ?

Merci de cette rapidité.

dh · 15 Juin 2005

ok

recupere le nom du fichier
ex 2.html
explode le /.
recupere le 2 qui est l'id et fait la requette

unlu · 15 Juin 2005

Faudra mieux t'exprimer parce que franchement g rien compris...

cloacking · 15 Juin 2005

Re-Bonsoir

Faudra mieux t'exprimer parce que franchement g rien compris...

En voilà un qui pourra pas m'aider :cry:
Désolé également mais j'avais dit que je m'exprimais mal qu'en t-il s'agissait de prog.
Effet panique surement !

SELECT enter,adresse FROM porte WHERE id=$id

Quel est cet $id

Car dans la première page, j'affiche déjà les personne et leur id en interrogeant ma base, donc j'ai sensiblement quelque chose de la sorte

Code:

echo ' <a href="'.$data['enter'].'">'.$data['enter'].'</a>'

Et idem pour le
('.$data['id'].')

Donc lorsqu'on clique sur le ('.$data['id'].')
On arrive ensuite sur ma page ref/index.php qui je le rappelle grâce à la réecriture devient ref/xxx.html

Voici ma réecriture

Code:

RewriteEngine on 
RewriteRule ^ref/(.*).html$ /ref/index.php [L]

Donc je cherche bel et bien à ce que ma page index.php corresponde à chaque fois à une page personnalisé en fonction de l'id.

Bon je sais comme cela ça parait encore moins clair :?
Même pour moi

jeroen · 15 Juin 2005

Je ne comprend pas ta rewrite rule.
le numéro (.*) doit etre transmis ?

Ca ce serait pas plutôt :

Code:

RewriteEngine on
RewriteRule ^ref/(.*).html$ /ref/index.php?id=$1 [L]

Dans ce cas, sur ta page tu récupérera l'id du membre grace à $_GET['id'] :

Code:

SELECT enter,adresse FROM porte WHERE id=$_GET['id']

rtb · 15 Juin 2005

tu peux passer l'id aussi dans l'url en reecriture, du stile bidule-id.htm
Ensuite tu explode l'url et tu recupere id et
SELECT enter,adresse FROM porte WHERE id=$id.
Autrement si bidule c'est le contenu d'un champ sans boublons de ta table tu peux aussi recuperer $nom=bidule et SELECT info1,info2,.... FROM porte WHERE nom=$nom

Patrice A. · 15 Juin 2005

jeroen a dit:
Je ne comprend pas ta rewrite rule.
le numéro (.*) doit etre transmis ?

Ca ce serait pas plutôt :

Code:

RewriteEngine on RewriteRule ^ref/(.*).html$ /ref/index.php?id=$1 [L]

Dans ce cas, sur ta page tu récupérera l'id du membre grace à $_GET['id'] :

Code:

SELECT enter,adresse FROM porte WHERE id=$_GET['id']

Bonne idée, mais fais

Code:

$id = htmlentities($_GET['id']);

avant la requête

Code:

SELECT enter,adresse FROM porte WHERE id=$id

Sinon tu ouvres une grosse faille de sécurité :wink:

Phix · 15 Juin 2005

Dj_apx a dit:
Bonne idée, mais fais

Code:

$id = htmlentities($_GET['id']);

Perso je fais tout le temps addslashes() pour les paramètres d'entrée, est-ce que c'est aussi efficace pour les tentatives de hack que le htmlentites()? Faut-il même carrément faire les deux?

shrom · 15 Juin 2005

Phix a dit:
Perso je fais tout le temps addslashes() pour les paramètres d'entrée, est-ce que c'est aussi efficace pour les tentatives de hack que le htmlentites()? Faut-il même carrément faire les deux?

Tu peux même en faire beaucoup plus car une requête du genre:

Code:

SELECT enter,adresse FROM porte WHERE id=$_GET['id']

reste vulnérable aux injections SQL même après un addslashes ou un htmlentities.

Si $_GET['id'] vaut

Code:

1 or 1=1

$_GET['id'] doit être un entier, il faut donc tester s'il est bien un entier ou au moins faire un cast.

Dans le cas présent, ce n'est pas très gênant mais bonjour la catastrophe avec une requête de mise à jour.

rtb · 15 Juin 2005

Dj_Apx a dit:
Bonne idée, mais fais

Code:

$id = htmlentities($_GET['id']);

avant la requête

Code:

SELECT enter,adresse FROM porte WHERE id=$id

Sinon tu ouvres une grosse faille de sécurité :wink:

Pas tres fort en prog, vous pourriez m'explquer pour la faille de securité ?

Phix · 15 Juin 2005

Shrom a bien expliqué, si tu as "1 or 1=1" dans $_GET['id'] et que tu fais la requête

Code:

SELECT enter,adresse FROM porte WHERE id=$_GET['id']

sans faire une vérification de paramètre ta requête sera:

Code:

SELECT enter,adresse FROM porte WHERE id=1 or 1=1

en d'autres termes, tu récupères tous les enregistrements.

Ici ce n'est pas grave mais imagine ce cas:

Code:

SELECT pseudo FROM users WHERE login='$_GET['login']' AND password = '$_GET['password']'

Il te suffirait de mettre dans $_GET['login']: "admin';#" pour avoir:

Code:

SELECT pseudo FROM users WHERE login='admin';#' AND password = 'nimportequoi'

ce qui permet de hacker une requete de connexion (# correspond à un commentaire en MySql). Bien sur là j'exagère mais cela montre l'importance de bien vérifier les paramètres d'entrée et ne jamais y faire confiance...

Quand j'ai découvert cela j'ai eu des sueurs froides en voyant que mon système d'authentification pouvait être cassé si facilement :lol:

Patrice A. · 15 Juin 2005

J'ai été un peu vite dans mon conseil, mais pour faire simple toute donnée entrée par un utilisateur est malveillante jusqu'à preuve du contraire.
il faut donc la rendre inoffensive avant de l'exploiter.
pour un élément à "trouver" dans la base (where)
on aura le plus souvent recours à addslashes(). s'il doit s'agir d'un entier on effectuera ensuite intval().

pour un élément à insérer ou mettre à jour, si on veut s'assurer d'éviter l'injection de code html, on emploierai htmlentities().

Si j'ai oublié quelque chose rafraîchissez-moi la mémoire svp.

rtb · 15 Juin 2005

Merci Phix, c'est plus clair la, c'est vrai que j'ai jamais cherché a hacker mais y'en a qui y joue pas mal, vaut mieux entre prudent

shrom · 15 Juin 2005

Dj_Apx a dit:
pour faire simple toute donnée entrée par un utilisateur est malveillante jusqu'à preuve du contraire.

Tout à fait d'accord

Code:

il faut donc la rendre inoffensive avant de l'exploiter.

Je dirais qu'il faut d'abord tester la cohérence de la donnée que tu attends. Si tu attend un numérique, tu testes si la valeur est numérique avec ctype_digit() par exemple, si elle ne l'est pas tu renvoie une erreur à l'utilisateur.

pour un élément à insérer ou mettre à jour, si on veut s'assurer d'éviter l'injection de code html, on emploierai htmlentities().

La il s'agit essentiellement d'éviter le Cross Site Scripting. Malgré le htmlentities, il reste le problème des injections SQL avec les quotes si magic_quotes_gpc est à off ( ce qui est une bone pratique pour assurer la cohérence des données dans le programme).

Patrice A. · 15 Juin 2005

shrom a dit:
pour un élément à insérer ou mettre à jour, si on veut s'assurer d'éviter l'injection de code html, on emploierai htmlentities().

Cliquez pour agrandir...

La il s'agit essentiellement d'éviter le Cross Site Scripting. Malgré le htmlentities, il reste le problème des injections SQL avec les quotes si magic_quotes_gpc est à off ( ce qui est une bone pratique pour assurer la cohérence des données dans le programme).

Code:

htmlentities($var,ENT_QUOTES)

devrait suffire à éliminer les guillemets simples et doubles

cloacking · 15 Juin 2005

Merci à vous pour ces explications et pour ces failles que je n'imaginais presque pas.

Sympa et rapide.