Bonsoir, 

Pour se connecter à mon site, j'ai réalisé une requête Sql en php 7 en mode  PDO, malheureusement, j'ai l'erreur suivante:

  Recoverable fatal error: Object of class PDOStatement could not be converted to string in C:\wamp64\www\ProjetStage\connexion.php on line 22

Votre aide m'est précieuse, merci.

et voici mon code:

<?php  
  session_start();
  require('includes/fonctions.php'); 
  
  require('config/maBase.php');

   // GESTIONNAIRE D'ERREURS DU FORMULAIRE D'INSCRIPTION

    if(isset($_POST['connexion'])){
        
         //SI aucun champ n'est pas vide
        if(not_empty([ 'identifiant', 'psw']) ){
            //extract($_POST);
            $pass=$_POST ['psw'];
           try{ $q=$db->prepare("SELECT FROM utilisateurs 
            WHERE (pseudo = :identifiant OR email = :identifiant)
            AND password= :psw AND active ='1' ");
            $q->execute([
                ':identifiant'=> $_POST['identifiant'],
                ':psw' =>  sha1($pass)
            ]);}catch(Exception $e){
                echo "<br>Erreur dans la requête :" .$q;
                echo "<br>erreur : ".$e->getMessage();
            }
           
            $userHasBeenFound = $q->rowCount();
            if($userHasBeenFound){
                redirect('profile.php');
            }else{
                set_flash('identifiants erronnés ', 'danger');
                save_input_data();
            }
           
        
            }
    }else{
        clear_input_data();
    }
   
 ?>

Bonsoir,

Pas de rowcount sur un select comme tu peux le lire dans la doc

$q est un Object of class PDOStatement donc tu ne peux pas l'afficher

Il ne manque pas quelque chose entre SELECT et FROM ?

> Pas de rowcount sur un select comme tu peux le lire dans la doc

Yep, autant faire un COUNT mais ça m'étonne que rien ne parte en session.

Le try/catch contre productif surtout si c'est pour tenter de convertir un PDOStatement en string (induit par ta concaténation de $q), ce qui n'est pas possible (elle n'implémente pas la méthode magique __toString). Et un SHA1 (sans salage !) ou comment faire un bond dans le passé.

> (pseudo = :identifiant OR email = :identifiant)

Peut se "simplifier" par :identifiant IN(pseudo, email) ce qui permet d'éviter les erreurs de précédence entre AND/OR et d'avoir un code portable (il n'y a que l'émulation qui permet l'emploi d'un même marqueur nommé plus d'une fois - et les SGBD à marqueurs nommés ?)

-
Edité par julp 13 juin 2021 à 0:34:07

Salut,

Désolé mais ton code pique les yeux, premièrement le nommage de tes variables et deuxièmement ton code n'est pas sécurisées face aux injections SQL 

Note : débutant ou pas, apprends les bonnes pratiques, car le développement Backend ce n'est pas du jeu

-
Edité par EL-jos 13 juin 2021 à 0:53:01

> ton code n'est pas sécurisées face aux injections SQL

D'où tu sors ça parce que sa requête est correctement préparée ?!?

-
Edité par EL-jos 13 juin 2021 à 1:14:53

> je pourrai bien m'amuser à voler sa bdd

Tu peux essayer longtemps, il n'y a pas d'injection SQL là ...

> Note : prepare ne sécurise pas une requête, mais ça te permet de préparer tes variables avant de créer une requête

Je pense que tu n'as pas compris le principe d'une requête préparée

> preuve prepare ne sais pas déduire que la valeur d'une variable est une attaque (injection SQL)

Gné ? Il n'y a pas de variable dans la requête qui est préparée ! Elles sont bindées, pas interpolées donc c'est correct.

-
Edité par julp 13 juin 2021 à 1:20:10

Et ce quoi selon toi ?

Note: si prepare savait déduire les attaques SQL sinon pourquoi, on l'utilise pas directement ? Au lieu de ses casser la tête avec certains vérification 

Voici ce que dis la documentation officiel : Note:

L'émulation de requêtes préparées ne communique pas avec le serveur de base de données. Aussi, la fonction PDO::prepare() ne vérifie pas la requête.

-
Edité par EL-jos 13 juin 2021 à 1:31:08

> Essaie tout simplement d'ajouter dans le mot de passe # ' et tu verras

Tu l'as fait toi au moins ? Avec une vraie requête préparée, les données bindées ne font pas partie de la requête donc ce n'est pas possible et vraiment pas l'idée. Tout le principe réside dans la séparation de la requête et des données, ce qui permet, même avec une émulation, de les échapper comme il faut. C'est sûr que si on les utilise mal, avec prepare, oui mais ne bindant pas les données et en les injectant directement dedans par concaténation ou interpolation, elle n'en sert strictement à rien.

> Note: si prepare savait déduire les attaques SQL sinon pourquoi, on l'utilise pas directement ? Au lieu de ses casser la tête avec certains vérification

Sauf que validations et sécurité, ce sont deux choses totalement différentes et bien distinctes.

-
Edité par julp 13 juin 2021 à 22:36:53

Tu peux voir mon poste précédent, je rajouter quelque chose qui pourrait t'intéresser

julp a écrit:

Sauf que validations et sécurité, ce sont deux choses totalement différentes et bien distinctes.

> L'émulation de requêtes préparées ne communique pas avec le serveur de base de données. Aussi, la fonction PDO::prepare() ne vérifie pas la requête.

Mais ça n'a rien à voir, "vérifier" n'est pas lié à la sécurité : c'est parce qu'avec l'émulation la requête n'est pas "compilée" par le SGBD dès le prepare (forcément, ce n'est pas une vraie requête préparée, c'est une requête normale qui est construite ensuite exécutée par PHP lors de chaque execute). Ca veut dire, que s'il y a une erreur de syntaxe (niveau SQL), avec l'émulation ça n'apparaît pas au prepare (contrairement à une vraie) mais qu'à l'appel à execute.

> Nous validons pour pour s'assurer que l'utilisateur ne nous attaque pas, n'oublie pas la règle d'or en Backend qui est de ne jamais faire confiance à un utilisateur

Non, validation c'est pour assurer au mieux la pertinence des données ou mettre en place des restrictions par besoin (ex : limiter les pseudos à des lettres + chiffres pour les mentions). La seule chose qui te prémunit d'une injection SQL c'est un échappement ou de préparer (correctement) ta requête. Une validation, c'est optionnel, elle peut évoluer et tu peux te planter (c'est pourquoi on les teste normalement au passage). Déjà vu ici : quelqu'un qui validait une adresse email par une regexp et qui avait oubié le $ : il comptait dessus pour ne pas l'échapper dans sa requête qui n'était pas préparée (énorme erreur), résultat : une injection SQL parce qu'on pouvait mettre ce que l'on voulait à sa fin ... Les validations ça vient en "complément", ça ne remplace surtout pas ce que l'on doit mettre en place pour les injections SQL, XSS et autres !

Il faudrait envisager de creuser le sujet pour être sûr que tu interprètes correctement ce que tu lis et ne te mettes pas non plus à répandre des choses qui sont fausses.

-
Edité par julp 13 juin 2021 à 2:02:11

Bonsoir à tous,

Merci pour vos contributions. Effectivement, j'avais oublié un 'id' entre le "select " et le "from" . Je crois j'étais un peu fatigué.

Merci encore.