Bonjour a tous.
Lorsque je fait requete dans phpmyadmin elle fonctionne mais lorsque je linsere dan mon code php ca ne marche plus. Avezvous une reponse. Merci
Voilala requete:
 
 $sql = 'SELECT * FROM `user` WHERE `login` LIKE \ 'dilob\' AND `pass` LIKE \'asd\' LIMIT 0, 30 ';  
 
L'erreur affichee est :
 
"Query was empty" alors que dans phpmyadmin il m'affiche bin la ligne contenant le login dilob et le pass asd

tu peux montrer ton code php: connexion à la base, execution de la requete et recupération des résultats, stp ?
edit: mais à l'instinct, je voterais pour un rtfm.

 
Voila mon code
function auth_user($login, $pass, $link)
{
 
 $db_selected = mysql_select_db('site');
if (!$db_selected)  
{
   die('Impossible de se connecter : ' . mysql_error());
}
 
  $selection = "SELECT * FROM `user` WHERE `login` LIKE 'dilob' AND `pass` LIKE 'asd' LIMIT 0, 30 ";
 
 $result =  mysql_query($seletion);
if (!$result)  
  {
    echo "Impossible d'executer la requete ($sql) dans la base : " . mysql_error();
    exit;
  }
 var_dump($result);
 
 echo $result;
 
 if (mysql_num_rows($result) == 0)  
   {
     echo "Aucune ligne trouve, rien a afficher.";
     exit;
   }
 
 
while ($row = mysql_fetch_assoc($result))  
{
   echo $row['pass'];
   echo $row['login'];
}
 

 $selection = "SELECT * FROM `user` WHERE `login` LIKE 'dilob' AND `pass` LIKE 'asd' LIMIT 0, 30 ";
 
 $result =  mysql_query($seletion);  
 

 
Ok, c'est cool. Ca fait un bout de temps que je cherche, Une erreur bete encore.
Maintenant imaginons qu'a la place de 'dilob' et 'asd' jai $login_in_db et $pass_in_db et que ensuite je les comparent a un formulaire(champs login + champs mot de passe) rempli par l'utilisateur.
Lorsque je met les variable ca ne marche pas.En faite je ne voit pas trop comment faire pour comparer ce que saisi l'utilisateur par rapport au contenu de la base de donnee.
Pourrai tu me dire comment faire ca srrai vraiment sympa de ta part
 
 
je fait un truk du genre :
$login = $_POST['login'];  
$pass = $_POST['pass'];
 
if(pass_in_db == $pass && login_in_db == $login)
echo "Authentification reussie";
else
echo "Auth echouee";
 
 
 

pass_in_db et login_in_db, elles sortent d'où ces variables
Tout ce que t'as à faire en gros (après, faut gérer le pb du sql injection) :  

 
Une fois le résultat obtenu, vérifier que la requête sql n'a renvoyé qu'un seul résultat.

 
C'est pas comme si on te l'avait fait remarquer il y a 3 jours et même expliqué comment les eviter en affichant les notices  

Ce serait peut-être une bonne idée oui, et vu le niveau de la personne je doute qu'elle comprenne le sens de l'expression et qu'elle recherche ce que ça signifie, prière donc d'éditer ton post en le réécrivant correctement stpmerssi

 
ça te va?
 
Bon, perso, pour éviter ce genre de pb, côté client, je hashe en md5 le login et le mdp. Comme ça, côté serveur, j'attends 2 variables de 32 caractères qui ne risquent pas de contenir de ', # ou autre joyeuseté et contourner mon système d'authentification...

Non.
 
1. stripslashes ne doit être utilisé que si magic_quotes_gpc est actif
2. J'aime pas l'intégration de valeurs comme ça dans les requêtes de DB, il n'est pas assez flagrant qu'on importe une valeur externe
3. Et tu devrais préciser que sous PHP5 on ne fait pas ce genre de merdes et on utilise mysqli ou PDO (qui sont nécessaires pour accéder correctement à MySQL >= 4.1 de toute façon)

Et si le client n'a pas de javascript?  

Donne moi l'URL d'une page où tu fais ça, et je te montre que je peux te balancer autant de ', " et # que je veux

ben ce sont des intranets. Donc pas accessible depuis l'extérieur.
Le coup du Javascript pas activté, je l'attendais celle là. Avec du md5, faudra que tu m'expliques comment tu mets le caractère # ou ' ou "...
 
Pour info, j'ai testé un certain nb d'ex d'injection extrait de ce site : http://www.phpsecure.info/v2/article/InjSql.php
J'ai pas de pb pour 4 raisons :
1) comme dit précédemment, le md5 ne contient pas de # ' "
2) j'attends 32 caractères pour chaque champ (login et mdp)
3) comme j'ai besoin d'un certain nb d'autres infos sur l'utilisateur (pour les stocker dans la session), je fais des jointures sur d'autres tables. Donc, en général elles vont échouer car j'aurai une réponse vide. Et je mets les conditions sur le login/mdp en fin de requête.
4) si tout s'est bien passé avant, je dois avoir au max, 1 réponse (utilisateur trouvé dans la bd), sinon 0.
 
Et pour ce qui est de mysqli ou PDO, je pense pas queça soit utile dès le départ de l'embrouiller avec ça.
 
sinon, pour php4, voici une petite fonction pour sécuriser trouvée sur http://www.netlobo.com/preventing_mysql_injection.html
 

Tant mieux

Ce qui n'enlève rien à la validité de l'argument

Tu valides que ce qui arrives à ton serveur ressemble bien à du MD5 avant de l'utiliser?

Embrouiller?

C'est simplissime et ça permet d'éviter 95% des injections SQL si on l'utilise correctement

 
Je vérifie juste si ça fait bien 32 caractères il est vrai. Pourquoi ce "laxisme"? Parce que mon appli se trouve dans un environnement déjà relativement bien sécurisé, coupé de l'extérieur et qu'il est facile en cas d'attaque d'un petit malin de remonter à lui.
Maintenant, je sais que mon système n'est pas infaillible. Mais suffit juste de vérifier que mes 2 chaînes reçues font bien 32 caractères et ne contiennent que 0..9 et a..f. Et là, je pense qu'on est pénard.

Là oui, mais il faut le faire, et il ne faut impérativement que l'utilisateur ait un support JS et le JS activé

 
ce qui est le cas sur le web dans une large majorité et, là où je travaille, toujours le cas, donc pas de pb

Ca, c'est typiquement le genre de trucs dont tu ne peux absolument pas être certain

là où je travaille, si...
 
Mais bon, on va pas épiloguer. Le gars voulait une réponse à son pb, il l'a eue. Je pense pas qu'on va lui prendre la tête pour savoir si le MCD de sa base est correct, s'il développe bien son appli avec une architecture MVC, s'il respecte bien toutes les recommandations du w3c et nianiani et nianiana    
 
Je pense qu'il débute; il va donc commencer par faire des choses simples et si ça lui plaît et l'intéresse, il apprendra "les bonnes manières" au fur et à mesure

lol...
(et en codant en PHP en plus, rien que ça)

mais de toute façon, si le magic_quotes_gpc est à ON sur le server, on s'en bat les cacahuètes nan?    
du coup si on les insère "en dur", sans htmlentities&co, dans la req SQL, ça craint pas. si?

Non, magic_quotes n'est pas une fonctionalité de sécurité c'est un trou de sécurité, l'encodage est trop générique et complètement incorrect, raison pour laquelle il ne faut surtout pas utiliser `addslashes` (qui fait exactement ce que fait magic_quotes).

En bonus, ça flinque les perfs (il faut escaper tout ce qui entre) et ça force à manuellement dé-escaper tout ce qui ne va pas dans la DB, créant non seulement un code illisible mais fusillant encore plus les perfs (puisqu'il faut appeler stripslashes sur tout ce qui rentre).

C'est pourquoi magic_quotes est désactivé par défaut dans PHP5 et a été totalement supprimé dans PHP6 (normalement)

Pour plus d'infos sur le sujet et les problèmes de sécurité liés à php, ce post fournit une liste.

ah quand même.  

J'ai du mal:
L'exemple que donne le mec, c'est avec le magic_quotes_gpc @ ON?

on peut bypasser le addslashes alors? mais comment?

le code ci-dessous sert à quoi en fait?

ça ressemble bien à une injection SQL mais je ne comprends pas l'utilité des chr() et ce que ça retourne.
tu voudrais bien expliciter Masklinn?

Mes scripts sont potentiellement vulnérables donc.  

ça ne vous effraie pas vous, qu'on puisse kicker magic_quotes_gpc dans les versions ultérieures?  

L'exemple que donne le mec est avec addslashes et sans magic_quotes, mais magic_quotes est strictement équivalent à utiliser addslashes sur toutes les valeurs de $_GET, $_POST et quelques autres ($_REQUEST aussi il me semble), donc la vulnérabilité potentielle est identique.

C'est marqué suffit de lire

En gros il faut utiliser des caractères multibytes invalides créant un caractères multibyte valide + le caractère 0x27 (la quote) quand on y insère un antislash.

Genre 0xbf27 (la valeur hexadécimale 27, correspondant à ' quand elle est utilisée seule): addslashes ne comprend pas les charsets multibytes, donc il tente d'échapper 0x27 ( ' ) en le préfixant par 0x5c (qui correspond au caractère \ ). Le résultat, c'est que le flux se retrouve avec 0xbf27 remplacé par 0xbf5c27. 0xfb5c étant un caractère multibyte valide dans l'encodage que l'auteur a choisi, on se retrouve donc avec un caractère 0xbf5c et un caractère 0x27... soit une quote seule... boum

chr retourne le caractère dont on donne le code, donc ici il retourne un caractère de code 0xbf et un caractère de code 0x27, soit la séquence dont je parlais au dessus, qui va se faire échapper partiellement (mais abusivement) et va donc placer une quote ( ' ) littérale dans la chaîne de caractères

Si tu utilises addslashes ou magic_quotes dans tes scripts oui, si tu utilises mysql_real_escape_string ou les Bound parameters de PDO ou mysqli non.

Si tu es dans le premier cas, passe vite dans le second, c'est un conseil.

Je ne comprends pas trop la question, demandes tu si ça nous fait peur que magic_quotes disparaisse (soit retiré) de PHP6? Si c'est le cas, absolument pas: comme le montre le lien que j'ai donné addslashes et magic_quotes ne sont pas des sécurités suffisantes, et sont donc des dangers.

 
   
 
Le problème en fait, c'est qu'au lieu de lire 0xbf, 0x5c et 0x27 -dans lequel cas le 0x27 est correctement échappé- le serveur lit en réalité 0xbf5c et 0x27 ?    
0xbf5c correspond à quel char?
 
Et en pratique, il faudrait saisir quoi dans un form avec deux input (login et pwd) pour exploiter la "faille" ?    
 
genre si je rentre mot pour mot dans le champ de saisi du login ceci:

ça ne fonctionnera jamais.    
 
ou ptet en passant par une modification des headers.  
 

j'y compte bien.    
merci
 

c'est ce que j'évoquais.    

Non, le serveur lit correctement 0xbf5c (qui est un caractère GBK valide) et 0x27 (un autre caractère GBK valide), le problème vient d'addslashes qui ne se rend pas compte que 0xbf27 devrait être considéré comme un caractère... parce qu'il ne comprend pas les encodages.

縗 -- correspond au codepoint unicode U+7E17

Aucune idée, mais en pratique quand on tente de trouver des failles on n'utilise pas les formulaires des pages, donc ce n'est pas un problème

Attends, je suis perdu:
1.le serveur reçoit 0xbf27
2.il se dit:
- "hola! j'ai comme l'impression qu'il y a deux chars ici : 0xbf et 0x27, héhé"
3.
- "donc j'escape 0x27 par prudence avec mon 0x5c"    
4.
- "tiens, ça donne 0xbf5c, mais j'ai pas l'impression qu'il y a deux chars cette fois-ci"    
5.
- "voilà j'ai terminé mon traitement, j'envoie mon rapport au visiteur : 0xbf5c et 0x27. hop c'est parti!"    
6.
- "eÿ, minute! j'me suis planté! j'ai envoyé un 0x27 sans l'échapper du coup, dans le lot; alors que j'aurai du envoyer 0xbf + 0x5c + 0x27 ... fais chier il va se faire hacker"    
 
 
c'est juste?    
[/quotemsg]
 
 

ah bah si le problème ne se pose pas moi je laisse mes addslashes.    
 

Non, c'est n'importe quoi.
 
1. PHP reçoit les octets 0xbf27 qu'il interprète comme partie d'une chaîne de caractères, PHP sait que sa chaîne est encodée en CJK et que 0xbf27 correspond à un caractère unique
2. Il est demandé au serveur d'addslasher la chaîne de caractères (via magic_quotes ou via addslashes), donc PHP appelle `addslashes` en lui filant la chaîne de caractère
3. addslashes, lui, ne connaît pas le CJK. En fait il n'a aucune notion d'encoding et ne se pose pas la question. En arrivant à 0xbf27, addslashes est donc incapable de déterminer que c'est un caractère unique, il "comprend" donc ces deux octets comme les deux caractères 0xbf et 0x27.
4. 0x27 correspond à une quote ( ' ), donc addslashes le remplace par 0x5c27, ou la paire de caractères \'
5. addslashes renvoie son résultat au reste du script PHP
6. PHP considère toujours que sa chaîne est en CJK (et dit à MySQL que la chaîne est en CJK). En lisant la chaîne en tant que chaîne CJK, PHP et MySQL voient donc maintenant deux caractères CJK: 0xbf5c (縗 et 0x27 (')
7. Boum
 

J'ai du mal à déterminer si

• Tu n'as pas lu ce que j'ai écrit
• Tu n'as pas compris ce que j'ai écrit
• Tu te fous de moi

ok, j'y suis. avoue que j'étais pas loin quand même. j'avais pas compris l'enjeu de l'encodage/charset.    
 

J'ai lu et je ne me permettrai pas de me payer la gueule de qqn qui veut bien m'accorder de son temps pour m'expliquer.    
 
merci, donc.

Bon, alors pour faire simple ton serveur reçoit des requêtes HTTP, un navigateur n'est rien de plus qu'un client HTTP qui est capable d'interpréter des réponse HTML (et autres) en tant que pages web. Fondamentalement, à partir du moment où on sait quelles données HTTP tu récupères (user/pass, les noms des champs et l'url à laquelle il faut l'envoyer) il n'y a plus besoin de passer par un navigateur: on peut passer par des outils spécialisés comme cUrl ou par les librairies HTTP d'un language qu'on connait comme urllib en Python (la liste de classe devrait te donner une idée de la flexibilité de ce genre d'outils), Net::HTTP et OpenURI en Ruby, HTTPClient en Java ou même curl ou HttpClient en PHP.
 
Aucun besoin, donc, d'utiliser le formulaire sur ta page pour t'envoyer des données.
 
Et donc aucune raison de se limiter à ce qu'il est possible d'écrire dans le dit formulaire, il est possible de t'envoyer littéralement tout et n'importe quoi.

ok, c'est le addslashes() que je captais pas, je ne m'attendais pas à ce que tu me parle du formulaire.    
Pour ce qui concerne les données transmises, oui, je suis d'accord, il n'est pas necessaire de passer par le form du site qui présente la "faille", on peut se débrouiller avec CURL ou coder son petit bot qui enverra les headers, en POST, qui vont bien. Ou, plus simple, il suffit d'éditer la page du site (donc le form) en local pour envoyer ce qu'on veut...
enfin...
 

Oui mais là le principe c'est de pouvoir envoyer les données textuelles amenant à la faille, donc sans être limité parce qu'on peut inscrire avec son clavier

voilà, exactement. c'est le "problème".
Si on veut exploiter la faille, en l'envoyant sous forme de texte, usuellement, c'est impossible.
Il faudrait pouvoir modifier le "flux" qui est envoyé au site ciblé.
exemple:
si on suppose que ce flux est:
 
0x&éé"é"tié"y&ié"y&ézqs_fdvxçg_dsç_fàç"_'&_é"'çé"'àçé"'ç_è_èç_èvxcvxcBLABLABLABLAB
 
 
il faudrait pouvoir le transformer en qqchose comme:
 
0x&éé"é"tié"y&ié"y&ézqs_fdvxçg_dsç_fàç"_'&_bf27é"'çé"'àçé"'ç_è_èç_èvxcvxcBLABLABLABLAB  
 
pour pouvoir pirater le site ciblé.
 
 
Mais bon, là c'est un exemple, je raconte de la merde, ça dépasse mes compétences, je sais pas comment ça se passe moi "derrière" le processus de http headers...
 
Je sais pas si je me fais comprendre d'ailleurs...  
 
 
 
Et je suis sûr que tu as une idée du comment on peut se débrouiller pour faire avaler ce 0xbf27 dans la req SQL.    

C'est ce que je suis en train d'essayer de t'expliquer: les libs HTTP que j'ai cité plus haut permettent d'envoyer des données arbitraires aux serveurs

lapin comprite, pancake sur la tête, toussaaa...
Tu entends quoi par données arbitraires?
Tu voudrais pas être plus explicite et/ou donner un exemple concret, un bout de code, qui montrerai en quoi cette faille est exploitable?
(On passe en MP si  tu veux...)
 
désolé si je suis lent, je code uniquement à mes heures perdues, en amateur, donc mes compétences sont bornées.  

Ben par "données arbitraires" j'entend "tout et n'importe quoi"

Demain si j'ai le temps, histoire de ne pas donner un code test qui ne fonctionne pas (j'ai ni PHP ni MySQL sur ma machine actuelle)