Aide dans une requetes

[NicoMSEvent]

Il y a déjà quelques autres sujets parlant de ça (la sécurité, les formulaires).

Inutile d'être agressif alors qu'on t'explique que tu fais des erreurs. Tout le monde passe par là. Personne n'a codé de manière parfaite dès le premier jour. Je t'ai mis un -1, je réviserai ma note lorsque tu seras un peu plus réceptif au critiques/conseils.

La critique est là pour montrer tes faiblesses. Ok, je suis d'accord avec toi, ça fait pas toujours plaisir, mais au moins ça te donne l'occasion de t'améliorer.

[Jeckel]

Ca c'est le meilleure moyen pour se faire pirater sa base de données :

$db->execute("select * from `players` where `username`=?", array($_GET['username']));

Heum Si tu serais lire le code tu aurais compris que Nous allons chercher le Username du Joueur que nous attackons et pas l'inverse ^^

Juste pour répondre sur ce point, mais il ne serait peut-être pas inutile de faire un sujet à part entière sur le sujet :

Imagine que l'utilise, dans l'URL, arrive à faire passer une valeur du type JECKEL\" OR \"1...

La requête exécutée va alors ressembler à ceci :

select * from players where username = "JECKEL" OR "1"

Ce qui va modifier complètement le résultat du code... certainement faire planter ton script, et il faut savoir que les messages d'erreur sont très souvent la première source d'information pour hacker un site.

Donc ensuite en tâtonnant il peut aller plus loin, en modifiant la requête comme ça :

select * from players where username = "JECKEL" UNION select * from users

Là notre utilisateur au lieu de charger tous les "joueurs" il charge tous les utilisateurs, sans doute avec leur mot de passe... et le coup de grâce :

select * from players where username = "JECKEL" UNION select mot_passe as username from users

Voilà la base d'une injection SQL, sachant que ça je te l'ai fait en aveugle, mais si tu as ce genre de code un peu partout, l'utilisateur peut rapidement avoir accès à toute ta base de données...

select * from players where username = "JECKEL" UNION show tables

lui donnera par exemple la liste des tables de ta base de données...

La solution ? tout d'abord ne jamais au grand jamais utiliser la valeur reçue de l'utilisateur directement, que ce soit pour une requête, ou pour un include, une ouverture de fichier ou autre...
Un premier traitement doit vérifier que la valeur reçue est présente (déjà) et ensuite qu'elle est "propre".

Dans ton cas, par exemple vérifier simplement qu'elle ne contient que des caractères alpha numérique serait suffisant. (a-zA-Z0-9 )

[blingcru2]

Ok je voi mais le problème est que si je fais pas avec * je vais devoir tout selectioner parce que et ses seulement dans la ville(les combats) il faut tout aller chercher les joueur les ville, la vie du joueur attaquant et defendeur, les poches, les marchandise en possesion, les arme etc mais qui implique que 3 table sur 27 ,

mais perso je vois pas comment il peux modifier sa ma requete .. il faudrais qu'il entre dans mopn hebergeur etc et la sil rentre la oula pagaille plus de 1000 site donc quelque gros vont planter

bon perso les mot de passe son crypter en md5 mais je sais que ses fesable de les déchiffrer

Sinon auriez-vous une idée comment changer cela ?

J'aimerais pas trop sa m'arrive dejas nous avons ouvert il y a pas une semaine et avons dejas bientot 200joueur ses pas tres interessant de tout perdre les données des joueurs et tres chiant pour les joueurs, qui devrais recommencer a 0

Pour les includes ses seulement aller chercher la colonne gauche la colone du haut (l'entete) et la colonne droite et le footer strictement a se que me sert mes includes ..sinon sa serais une page blanche ^^

[Globe]

Tu sais ce que ça veut dire GET ? Il suffit de modifier le lien pas de hacker ton hébergeur... Sinon déhasher un md5 si tu sais comment faire j'aimerais bien savoir parce que tout le principe est que ça ne soit pas possible.Ta requête utilises une valeur récupérée en get c'est pas bien compliqué de de deviner en quoi c'est dangereux.

[NicoMSEvent]

@globe : il existe des dictionnaires pour le md5 (le hash des mots "anglais" ou "français" ou des prénoms, ça fait déjà assez bien de possibilité, d'ou l'intéret d'avoir un mot de passe "fort" composé de MAJ/min, chiffres, caractères spéciaux, et ayant une certaine longueur), ou même le "grain de sel" (de préférence inconnu du visiteur) à ajouter a la fin du mot de passe, ce qui va mettre à mal ces dictinnaires

@blingcru2 : chaque base de donnée est indépendante sur un mutualisé, donc si une se fait pirater, c'est son problème "personnel"
Il ne faut pas confondre table et champs (partie d'une table). * sert à sélectionner tous les champs d'une table. "SHOW TABLES" va te montrer toutes les tables (juste le nom des tables, pas leur contenu)

Attention aussi a ne pas mettre de valeur définie par le visiteur dans l'include.

Très mauvais exemple :
tu pourrais appeler une page comme ceci : index.php?page=une_page_de_mon_site

ici ton index.php sur le répertoire /home/moi/www

include('header.php');

include($_GET['page']);

include('footer.php');

Si tu as une page ta page de connection à la DB (avec tes mots de passes) sont dans un répertoire pas accessible par le public, on va dire par exemple : /home/moi/ma_db/mes_mots_de_passe.txt
il suffirait d'appeler ceci pour qu'on puisse voir tes mots de passe : index.php?page=../ma_db/mes_mots_de_passe.txt

je te laisse imaginer ce que donnerai un : printr($$_GET['test']); ou un eval($_GET['test']);

[Globe]

@globe : il existe des dictionnaires pour le md5 (le hash des mots "anglais" ou "français" ou des prénoms, ça fait déjà assez bien de possibilité, d'ou l'intéret d'avoir un mot de passe "fort" composé de MAJ/min, chiffres, caractères spéciaux, et ayant une certaine longueur), ou même le "grain de sel" (de préférence inconnu du visiteur) à ajouter a la fin du mot de passe, ce qui va mettre à mal ces dictinnaires

Mais ça ne change rien pour le hacker, crypter reste une bonne mesure, il n'y à pas de moyen de se prémunir de ça, on peut seulement insister sur l'importance d'utiliser des mots de passe complexes pour les utilisateurs. Le cryptage du mot de passe reste important et ça va contre toute éthique de ne pas le faire ! Je me sentirais assez honteux d'avoir en clair les mots de passe de membres. Mais pour moi ça ne rentre pas dans les mesures de sécurité simplement dans les règles de bon sens comme d'ailleurs de ne pas balancer d'informations sensibles en GET et ne pas réutiliser les valeurs sans les "nettoyer" surtout dans des requêtes =O

[Anthor]

NE PAS CONFONDRE HASHAGE ET CRYPTAGE !!!

[Globe]

Oui bon j'ai inversé les mots mais tout le monde à compris qu'on parlait de hashage non ?

[Jeckel]

Oui bon j'ai inversé les mots mais tout le monde à compris qu'on parlait de hashage non ?

Attention aussi avec le hashage, il n'est pas unique, c'est à dire que deux chaines différentes peuvent avoir le même hash... ce qui n'est pas la cas avec un cryptage (normalement).

Sinon, oui, l'utilisation d'une graine (ou grain de sel) dans le cryptage du mot de passe est un plus...

Le truc encore mieux est de rajouter un champs dans la table qui contient un hash des champs critisques (+ une graine) qui est recalculée à chaque mise à ajour, et vérifiée à chaque select... ça permet de détecter les modifications faites par une source extérieure (phpMyAdmin vérolé par exemple)

Si c'est pas clair, je peux détailler...

[NicoMSEvent]

@Jeckel: intéressant... mais couteux en ressource, non?
Sur mon projet avec la POO, je m'aperçois que je reconstruis en mémoire tout a chaque chargement de page.
Il en résulte que je passe de +-30 requetes (en sélection) par page (en procédural) à +-200 (en POO) parce qu'il y a de nombreux objets dont je n'ai pas besoin qui se rechargent (c'est peut-etre une mauvaise gestion de ma part).
Sur une offre d'OVH perso (celle à 2.5€/mois), ça reste fluide (pas testé avec une montée en charge de plus de 5 visiteurs simultanés), principalement grace aux index bien placés et à la bonne structure des requetes