1er donner un nom a la table que si le hacker le devine il ferait mieux d'aller jouer au loto.

Non ce genre de protection ne fait qu'ennuyer les programmeurs et les les utilisateurs normaux.

Le danger reste.

C'est un peut comme ne pas proteger une page d'admin mais la mettre dans un répertoire qui s'appelle nesbbm436 ou bkwr565Ynergns

il suffit d'une panne mysql ou php ou d'un message d'erreur et paf le truc pseudo secret est dévoilé
et bien pire encore on ne s'en rend souvent pas compte.
Et le pirate a tout son temps.

Il faut trouver comment filtrer au mieux ses données entrantes.

C'est effectivement un bon départ

Merci bien a tous pour ces reponses.
Je vais donc prendre des mesures pour securiser la base.
1er donner un nom a la table que si le hacker le devine il ferait mieux d'aller jouer au loto.
2eme changer le nom du champ 'id'.
Ca devrait suffire non?

oui c'est utilisable

par exemple avec un ou le priate mets $a = "pwet' or 1;# "
et qui retourne tout quelque soit la condition initiale

juste au passage, mysql_query n'accepte qu'une seule requête SQL à la fois

mais le principe exposé reste valable, il peut arriver de modifier le code d'une requête envoyée...

Ah ! Ça me rassure

Mais quand même, quel genre de "triche" on risque avec une utilisation comme celle que j'ai décrite plus haut ? J'en suis découragé d'avance s'il me faut changer toute mes requêtes dans mes sites

il y a plein de ressources sur le web on peut se faire une liste d'url ici non ?
et on les rajoute toutes dans le 1er post du thread

juste au passage, mysql_query n'accepte qu'une seule requête SQL à la fois

mais le principe exposé reste valable, il peut arriver de modifier le code d'une requête envoyée...

C'est ça, mais avec simplement un codage propre, tu vas limiter les dégats. Partons de taq requête:

SELECT * FROM table WHERE id='$_GET[id]'"

Dans un cas comme celui-ci, tu te sers d'un numérique comme point de repère : La première chose à faire est de ne pas utiliser $_GET['id'] dans la requête elle-même. Tu feras donc la chose suivante:

$id = isset($_GET['id']) ? $_GET['id'] ? "";
if(is_numeric($id))
{
    $sql = "SELECT * FROM table WHERE id='". $id ."'";
}
else
{
    echo("<p>L'identifiant est inccorect, veuillez sélectionner à nouveau votre article</p>\n"); // par exemple...
}

Là, tu court-circuite toute tentative d'ajout parce que si l'identifiant n'est pas un numérique, il n'y aura pas de requête du tout, donc si un petit futé ajoute quoique ce soit, c'est loupé d'avance.

Oops, déjà répondu... Je recommence, désolé :

J'ai regardé ça plus attentivement... cela signifie que pour une requête de type "SELECT * FROM table WHERE id='$_GET[id]'", si un utilisateur quelconque connaît, devine ou essaye au hasard un nom de table existant sur la base, il peut simplement en ajoutant "15; DELETE * FROM table" supprimer une table entière ?

Parce que des requêtes comme ça, j'en utilise plein

Eeeuh il commence sérieusement à m'inquiéter ce sujet

Faut pas non plus devenir parano, mais il est important de le savoir. Une programmation propre et une discipline de codage sont les prmières règles à observer. Ensuite, la règle d'Or que j'ai cité plus tôt : ne jamais faire confiance aux données de l'utilisateur. Enfin, faire en sorte que des données qui interviennent d'une manière ou d'une autre vers une base de données soient traitées correctement justemet pour éviter que des petits malins ne fassent les caves. Il y a sur PHPFrance un excellent tuto sur la manière de traiter des données avant envoi vers une base de données : les magic_quotes à lire attentivement et à prendre au sérieux.

Si un pirate du dimanche vous met un livre dor par terre, ça n'aura pas d'autre conséquence qu'une frustration et une envie de pendre le malfaisant pas les oreilles au sommet de la tour Eiffel un soir d'hiver venteux. Imaginez maintenant qu'il s'agisse d'un site de vente en ligne qui gère des milliers d'articles différents ... je vous laisse deviner ce que ça peut représenter comme catastrophe.

Eeeuh il commence sérieusement à m'inquiéter ce sujet

Edit : j'ai regardé ça plus attentivement... cela signifie que pour une requête de type "SELECT * FROM table WHERE id='$_GET[id]'", si un utilisateur quelconque connaît, devine ou essaye au hasard un nom de table existant sur la base, il peut simplement en ajoutant "15; DELETE * FROM table" supprimer une table entière ?

Parce que des requêtes comme ça, j'en utilise plein

Je commence a comprendre mais c'est pas encore tout a fait clair aussi je vous donne l'url de la page et vous demande d'inserer une requete pas trop mechante svp pour voir le resultat
http://charles.cc30.free.fr/msn/actu/news.php

c'est pourquoi je ne comprends pas comment on pourrait inserer des données malveillantes puisque ce n'est pas pour inserer mais juste recuperer et afficher

imagine que ta requete soit et que quelqu'un marque Dans l'url. la requete generée est donc Et tu te retrouve avec une table en moins parce qu'il y a des noms de tables qui reviennent souvent : user, commande, produit

Tu t'immagines perdre une table de commandes ?

Bon, ok, je vais essayer d'être moins abscons.

La méthode get transmet des données en les concaténant à l'utl. On les récupère ensuite sur la page dans la super-globale $_GET. Jusque là, je ne t'apprends rien. Les limites de cette méthode restent cependant importantes: la longueur d'une url est limitée selon les navigateurs entre 400 et 700 caractères environ. Le problème qui peut se poser en outre, c'est que l'internaute peut modifier les données de l'url pour faire afficher autre chose que ce qu'il a le droit de voir. Par exemple, on envoie par l'url des informations sur un bon de commande et on adjoint aux dnnées de l'url un numéro de client : si on modifie manuellement le numéro de client et que la récupération des données n'est pas rigoureuse, on risque de voir des petits malins se ballader dans les bons de commandes de toute le monde. On peut penser qu'un concurrent peu scrupuleux pourrait ainsi se forger une base de connaissance sur ta clientèle afin de cibler une attaque commerciale.

Un autre problème que pose la méthode get est le référencement des pages dans les moteurs de recherche : des moteurs comme Google n'acceptent pas plus de deux paramètres pour indexer une page. On peut toutefois contourner ce problème avec l'url-rewriting.

Alors je ne sais pas si ça répond à ton interrogation : dans le cas contraire, essaye de m'illustrer ton propos par un exemple type de ce que tu veux faire. J'ai bien une vague idée, mais je ne suis pas sûr et il est possible qu'une des solutions envisageable ne soit ni get ni post mais des variables de session.

Merci.
dans mon cas il n'est pas quetion de transmettre des données a inserer dans la base par la $_GET mais simplement de lire une information dans la base c'est pourquoi je ne comprends pas comment on pourrait inserer des données malveillantes puisque ce n'est pas pour inserer mais juste recuperer et afficher donc je ne vois pas comment m'en proteger .
Je suis lourd (hein) mais franchement je debute et j'aimerais comprendre