ah non c'est bon je le vois, j'ai été déconnecté c'est pour ça je pense

merci

[quote="@rthur"][quote="donkeykick"]Euhhh, le bouton résolu a disparu :shock: 8-| :-?[/quote]
J'ai apporté une petite modif au code qui gère le bouton résolu, est-ce que tu peux vider ton cache et me dire si tu le revois ?[/quote]

salut arthur, non je ne vois pas le bouton.

c'est comme ci je n'étais pas propriétaire de mon topic.

a ta disposition pour d'autres tests.

do_ok

[quote="donkeykick"]Euhhh, le bouton résolu a disparu :shock: 8-| :-?[/quote]
J'ai apporté une petite modif au code qui gère le bouton résolu, est-ce que tu peux vider ton cache et me dire si tu le revois ?

bonjour,
de retour, j'avais pas vu ta sur réponse @rthur.
ca devrait le faire maintenant, merci bcp !
je passe le post en résolu ;)

Euhhh, le bouton résolu a disparu :shock: 8-| :-?

Bonjour,

Pour les requêtes préparées avec PDO, il y a des exemples complets dans la doc : https://secure.php.net/manual/fr/pdostatement.bindparam.php#refsect1-pdostatement.bindparam-examples

Pour filtrer correctement ses données, PHP a une fonction filter_var() qui est très facile a utiliser : https://secure.php.net/manual/fr/function.filter-var.php

voila pour l'exemple :
$sth->bindParam(':calories', $_POST["calories"]);

Waouh ça craint le xss !!!

Typiquement pour protéger en PDO ta variable ça se passe comment ?

Est-ce que vous avez un exemple de code simple d'usage PDO avec des requêtes préparées protégées ?

J'adore ta signature ryle, tellement vrai :lol:

do_ok

Il est tout à fait possible de faire des injections en GET (c'est même d'autant plus facile qu'il suffit juste de modifier l'url de la page), tout comme tu peux le faire en POST, ou en bricolant la valeur d'un cookie. La règle est simple : il ne faut jamais faire confiance à une donnée dont tu ne maîtrises pas la provenance ou le contenu (input utilisateur, site externe, fichier d'import, ...) :)

Comme l'indique xTG, la première chose à contrôler est le type de valeur que tu reçois : si tu attends un nombre, tu ne dois pas te retrouver avec des lettres ou des caractères spéciaux, si tu attends une date, il faut que celle-ci soit valide, si tu attends une valeur sélectionnée dans une liste, il faut que celle-ci soit bien présente dans la liste etc.

Une fois que tu es certain que le type de donnée reçu est le bon, le second contrôle à mettre en place concerne les chaines de caractères soumises par l'utilisateur et que tu enregistres en base pour te prémunir des "injections SQL". Pour cela, les requêtes préparées et le bindParam de PDO fonctionnent bien et gèrent les caractères spéciaux de la chaine reçue (après tu peux aussi utiliser des mysqli_real_escape_string() ou fabriquer un contrôle maison).

Le troisième élément dont il faut se méfier c'est le "cross site scripting" ou "XSS". Cela consiste à envoyer du code html et javascript sur ton site qui va potentiellement l'enregistrer mais qui va surtout afficher celui-ci. Tu peux ainsi te retrouver avec des liens non désiré (ou bien pire avec du javascript) dans une des pages de ton site et permettre d'exécuter un code malicieux chez tout ceux qui ouvriront la page en question sur ton site.

Après il faut aussi se prémunir du spam, des attaques bruteforce, et de plein d'autres choses en fonction de l'attrait et de la confidentialité des données, mais déjà si tu gères les 3 cas ci-dessus, ton site sera bien plus sécurisé que nombre de site sur lesquels tu peux surfer ;)

On peut faire de l'injection avec n'importe quoi qui provient de l'utilisateur/navigateur.

$_POST['calories'] doit être un entier ou au pire un chiffre.
Tu as la fonction is_number qui peut t'aider à faire ce test, ou bien is_integer si tu veux aller plus loin.

Ok mais sur cet exemple ça donne quoi ?
$sth->bindParam(':calories', $_POST["calories"]);

Concernant les GET on peut aussi faire de l'injection ?

Il FAUT rajouter des contrôles.
On traite pas une variable sans la contrôler en se disant que la protection SQL suffit.
C'est bête de se retrouver à vouloir stocker un entier qui n'en est pas un.

Merci pour les astuces ;)

Du coup le fait de faire $sth->bindParam(':calories', $_POST["calories"]); suiffit ou il faut rajouter des contrôles ?

Idem est-ce qu'on faire des injections via l'url en récupérant des variables postées en GET.

Comment se gère la réécriture d'url à ce niveau ? (je sais c'est j'ouvre une parenthèse mais c'est pertinent je pense au vue du sujet)

do_ok

'SELECT name, colour, calories FROM fruit WHERE calories < ' . $_POST['calories']

SELECT name, colour, calories FROM fruit WHERE calories < 250
UNION 
SELECT username as name, password as colour, id as calories FROM users

Bonjour,

Ce n'est pas tant la requête préparée qui est importante, mais le fait de contrôler les données transmises par l'utilisateur.

Dans la logique, la requête préparée ne devrait servir que lorsque tu exécutes plusieurs fois la même requête de façon consécutives avec des valeurs différentes (ex : insertions ou mises à jour en masse, exécution de la requête dans une boucle, ...). Le gain de temps et de ressources est alors notable sur de gros volumes de requêtes.
Lorsque tu utilises PDO, ce dernier va implicitement protéger toutes les valeurs transmises à la requête préparée. C'est pourquoi beaucoup de gens l'utilisent ou recommandes PDO, même pour des requêtes simples qui ne seront exécutées qu'une fois dans le code.

Le contrôle des données transmises et la protection des injections sql évoqué par xTG est primordiale, car sans cela un utilisateur malintentionné pourrait en cherchant un peu, accéder à des données confidentielles de ton site (identifiants, mots de passe, ...).
Pour reprendre l'exemple et la requête donnés plus haut :
[php]'SELECT name, colour, calories FROM fruit WHERE calories < ' . $_POST['calories'][/php]Dans une logique fonctionnelle, $_POST['calories'] devrait contenir un nombre (saisie ou sélectionné dans ton formulaire) et tout fonctionnera bien. Dans la pratique, s'il s'agit d'un champ de saisie libre (mais ça marche avec n'importe quel type de champ si on bricole le html), il suffit à l'utilisateur de rentrer une valeur du type : " 250 UNION SELECT username, password, id FROM users " pour que la requête SQL exécutée devienne
[sql]SELECT name, colour, calories FROM fruit WHERE calories < 250
UNION
SELECT username as name, password as colour, id as calories FROM users[/sql] et retourne effectivement tous les éléments inférieurs à 250 ca, mais également la liste des identifiants et des mots de passes de la table users... Et si ça ne marche pas car la table ou la colonne n'existe pas, il suffit de changer le nom de la table et/ou des champs jusqu'à ce que ça fonctionne (et on peut même demander à un robot d'essayer des combinaison jusqu'à trouver les bonnes valeurs :))

En contrôlant que la valeur de $_POST['calories'] est bien un nombre avant de l'envoyer dans ta requête, tu t'épargnes ce genre de problème. De la même manière, avec les chaines de caractères, si tu ne contrôles pas la présence d'apostrophes ou de guillemets, l'utilisateur peut ainsi compléter ta requête et disposer d'un accès à ta base de données et peut être plus :)

La différence c'est que tu passes par prepare qui génère une requête préparée dans laquelle tu ne peux rien injecter hormis des données saines.
Tu peux mettre ce que tu veux dans le bindParam sans risquer d'injection SQL.

Alors que tout ce qui est dans le prepare doit être sain.

$sth = $dbh->prepare('SELECT name, colour, calories
    FROM fruit
    WHERE calories < :calories AND colour = :colour);

$sth->bindParam(':calories', $_POST["calories"]);
$sth->bindValue(':colour', $_POST["colour"]);

:lol:

Dans ton exemple si je fais :

[php]$sth = $dbh->prepare('SELECT name, colour, calories
FROM fruit
WHERE calories < :calories AND colour = :colour);

$sth->bindParam(':calories', $_POST["calories"]);
$sth->bindValue(':colour', $_POST["colour"]);[/php]

c'est bon ? Rien besoin de rajouter ? J'ai du mal à voir la différence entre le code ci-dessus et si je faisais calories < $_POST["calories"] AND colour = $_POST["colour"]..... J'ai peut être oublié un truc dans le bindParam :-k

do_ok