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 ?)
Regarde comment il récupère le mot de passe utilisateur à la ligne 14, et je pourrai bien m'amuser à voler sa bdd
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, preuve prepare ne sais pas déduire que la valeur d'une variable est une attaque (injection SQL)
- Edité par EL-jos 13 juin 2021 à 1:14:53
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
Essaie tout simplement d'ajouter dans le mot de passe #\' à la fin et tu verras
julp a écrit:
Je pense que tu n'as pas compris le principe d'une requête préparée
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
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
> 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.
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.
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
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
> 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.
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.
EUREKA! EURKA! EUREKA! en fait je galère :-)
requête de connexion en PHP
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Activer les erreurs PDO / (julp) htmlspecialchars / FAQ PHP / Pas d'aide par MP
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
Ton présent détermine ton futur et la connaissance te placera au dessus de ta génération .
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli