Encodage dans un site mélant Ajax et POST et protection des chaines

Bonjour,

Je développe en ce moment un site utilisant les formulaires classiques POST ou GET et Ajax pour insérer des données dans ma base MySQL.

Je souhaiterai déterminer quelle méthode utiliser pour protéger mes scripts contre les attaques de type XSS ou injection SQL.

Au départ, j'utilisais htmlentities() mais j'ai l'impression que c'est loin d'être la meilleure méthode. J'ai ensuite pensé à utf8_encode() et son inverse utf8_decode() qui semble par-ailleurs être obligatoire avec Ajax mais je ne suis pas sûr que ce soit la solution utlime pour parser les chaînes avant insertion en base de données.

Quelle solution utilisez-vous pour sécuriser les entrées des internautes avant traitement/enregistrement en base de donnée sur un site mélant POST/GET et Ajax ?

Merci pour vos réponses.

pH

utf8_encode, utf8_decode, htmlentities et htmlspecialchars ne font absolument aucune protection contre les injections SQL.
Htmlspecialchars protège par contre des failles XSS, il faudrait idéalement l'utiliser avant chaque affichage.

Pour les injections SQL, voir
- PDO::quote si tu utilises PDO
- mysql_real_escape_string si tu utilises l'ancienne API MySQL

Bonjour et merci pour ta réponse.

Htmlspecialchars seulement à l'affichage ? C'est suffisant ? Aucun traitement avant enregistrement ?

J'utilise PDO.

J'aurai bien utilisé la méthode prepare() mais j'avoue que j'ai un peu de mal avec leurs exemple ...

pH
Modifié par Pierre-Henri (31 May 2010 - 11:57)

L'idéal est de ne pas altérer les données enregistrées en BDD, d'où l'utilité de l'utiliser Htmlspecialchars qu'à l'affichage et protéger ainsi des attaques XSS.
En revanche il est important de préparer les données (mysql_real_escape_string ou PDO::prepare()) avant d'être enregistrées pour éviter les attaques par injection SQL.

Bonsoir et merci pour vos réponses !

Finalement, en cherchant un peu, je me suis mis aux requêtes préparées avec PDO. C'est simple et à mon avis très efficace puisque étudié pour contrer les injections (?)

Qui plus est, ça donne un code plus propre puisque l'ensemble des champs à remplir sont dans des array() qu'on peut indenter et présenter en colonne dans le script.

Que des avantages en fait !

pH

Bonjour,
Moi je suis toujours heureuse de voir des développeurs, se jeter dans PDO.
Alors deux trucs toujours utils
Ne jamais émlanger PDO et MySql ça parair banal mais bon
Alors justement le deuxiéme truc découle du premier et rejoint ton avis sur la simplicitée et clartée de PDO

Si tu rajoutes a l'ouverture (connection) de ta base:

$bdd->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Plus besoisn de OR DIE (interdit bien sur) donc une fois pour toute
ta gestion des erreurs est assurée sur toute ta page !
HOP THIS HELP

Bonjour,

Je n'utilise jamais de or die(); tout simplement parce que je trouve ça très moche et "bloquant".

Ceci dit, je ne comprends pas bien ta méthode pour gérer les erreurs.

Celle que je connais dans PDO est de faire un try{}.

Pour gérer les erreurs, je regarde le bool retourné par les méthodes execute de PDO. Si ça retourne false, j'affiche une erreur issue de mon fichier de langue. Je trouve ça plus propre.

pH

Bonjour,
Je me permets quelques "ajustemnt",
moust totalement d'accord avec toi, Htmlspecialchars parfait si affichage (hors textarea qui n'est pas interprété) ,
Ok aussi ==> surtout pas dans la base de donnée pour ne pas l'encombrer.

Par contre pour les XSS il reste a se protéger des OR AND != = etc ...
ce qui a mon sens insite a se faire une simple petite fonction securise()
Afin d'étre plus complet dans son barage aux attaques.
Mais il est encore plus simple de protéger dans les commandes SQL les variables par "'" .

Tout le monde sais que dans un controle de login,
le pseudo "toto or 1=1" ne contient aucun caractére traité par htmlspecialchars
et pourtant dan Mysql WHERE pseudo =toto OR 1=1 validerait le login.
avec la protection on obtient

WHERE pseudo ='toto OR 1=1' et voila qui compléte la sécurisation !

Pierre-Henri TRY n'a rien a voir avec la gestion des erreurs dont je parlais,
try et catch captent uniquement les erreurs de connection entre PDO et SQL
Alors que
$bdd->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
qui se mets aprés cette connection, gére toute erreur de requétes
sans que tu ais a rappeler cette fonction !
C'est un énorme avantage.

QuentinC
Tu dis
Pour les injections SQL, voir
- PDO::quote si tu utilises PDO
- mysql_real_escape_string si tu utilises l'ancienne API MySQL

J'ajouterais, (car je n'utilises que cela), que

- PDO::prepare fait tout tout seul comme un grand !
Modifié par Christele (10 Jun 2010 - 16:32)