HtmlEntities vs vs addslashes mysqli_real_escape_string

Question

Je l'ai fait un peu de lecture sur la sécurisation des applications PHP, et il me semble que mysqli_real_escape_string est la fonction correcte à utiliser lors de l'insertion de données dans des tables MySQL car addslashes peut causer des choses étranges se produire pour un attaquant intelligent. Droit?

Cependant, il y a une chose qui me prêter à confusion. Je crois me souvenir avoir été informé addslashes est mieux que htmlentities lorsque l'écho des données entrées par l'utilisateur retour aux utilisateurs de protéger leurs données, mais il semble que addslashes est celui avec la vulnérabilité. Est-ce vrai, ou suis-je rappelais à tort?

Answer 1

Il existe différents contextes pour vos données. Le contexte de l'insertion de données dans la base de données doit être échappé différemment que le contexte de rendu html / xml ou même un message électronique.

données Échapper entrer dans une db doit être dépréciée dans tout le nouveau code en faveur des déclarations préparées. Toute personne qui vous dit est sinon vous fait un très mauvais service.

données Échapper aller au navigateur doit être échappé dans un certain nombre de façons différentes en fonction de la cible. Parfois, htmlspecialchars suffit, parfois, vous devez utiliser htmlentities. Parfois, vous avez besoin d'entités numériques. Il est un sujet que vous devriez faire des recherches sur de connaître toutes les nuances.

La règle générale, je vis est valide (pas filtrer, rejeter si elles sont incorrectes) entrée et sortie échappement (en fonction du contexte).

Answer 2

Ils sont différents outils à des fins différentes.

mysqli_real_escape_string rend les données en toute sécurité pour l'insertion dans MySQL (mais les requêtes paramétrées sont mieux).

HtmlEntities fait des données en toute sécurité pour la sortie dans un document HTML

addslashes fait des données en toute sécurité pour quelques autres situations, mais il est insuffisant pour MySQL

Answer 3

Vous pouvez également utiliser le AOP libs qui fait la plupart des Escaping pour vous, au cas où vous pouvez utiliser sur les serveurs PHP5.

En écho de retour personnellement je préfère htmlspecialchars, mais on peut me corriger

Answer 4

oui, utilisez le mysqli_real_escape_string ou une bibliothèque comme AOP sur toutes les entrées utilisateur. Lorsque l'écho de retour, je l'utilise avec htmlentities ENT_QUOTES comme second paramètre, car il échappe à tous les caractères applicables à leurs entités html, y compris les guillemets.

Answer 5

Remarque: L'utilisation htmlentities () dans un document codé UTF-8 doivent être évités. Voir:

• Interfaçage avec d'autres systèmes utilisant Charsets
• communs zones Problème avec UTF-8

Faites attention à (cité phpwact.org ):

  

Avec les navigateurs web modernes et widespead   soutien UTF-8, vous n'avez pas besoin   htmlentities parce que tous ces   caractères peuvent être représentés directement   en UTF-8. Plus important encore, en   général, les navigateurs HTML uniquement de support   caractères spéciaux - un texte normal   éditeur, par exemple, ne connaît pas   entités HTML. Selon ce que   vous faites, en utilisant htmlentities peut   réduire la capacité des autres systèmes à   « Consommer » votre contenu.

     

En outre (non confirmé, mais les sons   raisonnable - de commentaire anon ici),   entités de caractères (trucs comme »ou -)   ne fonctionne pas lorsqu'un document est servi   application / xml + xhtml (à moins que vous   les définir). Vous pouvez toujours sortir   avec la forme numérique bien.

Answer 6

Une autre solution intéressante pour PHP 5.2 et ci-dessus est d'utiliser l'extension du filtre: http://www.php.net/manual/en/book.filter.php

Il vous permet de valider et désinfectez les entrées utilisateur. Il y a beaucoup de filtres intégrés disponibles et ils peuvent être combinés avec des drapeaux à modifier leur comportement. En outre des filtres peuvent également être es utilisés pour valider / désinfectez ints, flotteurs, e-mails, des expressions régulières spécifiques.

J'ai personnellement commencé à les utiliser dans mes projets pour valider les formulaires et les données entrées par l'utilisateur sortie, et je suis très content d'avoir fait. Bien que, lors de l'insertion des valeurs dans une base de données MySQL, j'utilise des requêtes préparées pour plus de sécurité. Ces solutions ensemble peuvent aider à éviter la plupart des injections SQL et des attaques de type XSS.

Answer 7

Vous ne pouvez pas avoir une fonction « échapper » et espérer qu'il fonctionne tout le temps. Il existe différentes attaques qui nécessitent des routines d'assainissement spécifiques. La seule façon de comprendre ce concept est d'écrire un code vulnérable, puis l'exploiter. L'écriture de code exploit est essentiel à la compréhension de tout système de sécurité.

Par exemple cette requête est vulnérable à l'injection sql:

$host=htmlspecialchars($_GET[host],ENT_QUOTES);
$name=htmlspecialchars($_GET[name],ENT_QUOTES);
mysql_query("select * from user where Host='$host' and Name='$name' ");

Exploit: http: //localhost/sqli_test.php host = \ & name =% 20sleep (20) - -% 201

La meilleure fonction d'échappement pour MySQL est mysqli_real_escape_string () mais cela peut échouer:

mysql_query("select * from user where id=".mysqli_real_escape_string($_GET[id]));

exploiter: http: //localhost/sqli_test.php id = 1% 20ou% 20sleep (20)

En fait, la meilleure façon de prendre soin de l'injection sql ne demande pas une fonction d'échappement, Son à l'aide des cahiers de paramétrés de ADODB pour injection sql. Utilisez htmlspecialcahrs ($ var, ENT_QUTOES) pour XSS. Lire le OWASP top 10 parce qu'il ya beaucoup plus que ce qui peut aller mal avec web la sécurité des applications.