PHP: mysql_real_escape_string est-il suffisant pour nettoyer l'entrée utilisateur?

Question

mysql_real_escape_string suffisant pour nettoyer les entrées de l'utilisateur dans la plupart des situations?

::MODIFIER::

Je pense surtout à la prévention de l'injection SQL, mais je souhaite enfin savoir si je peux faire confiance aux données des utilisateurs après l'application de mysql_real_escape_string ou si je dois prendre des mesures supplémentaires pour nettoyer les données avant de les transmettre à l'application et aux bases de données.

Je vois où le nettoyage des caractères HTML est important, mais je ne le considérerais pas nécessaire pour faire confiance aux entrées de l'utilisateur.

T

Answer 1

mysql_real_escape_string n'est pas suffisante dans toutes les situations, mais il est certainement très bon ami. La meilleure solution est d'utiliser les requêtes Préparées

//example from http://php.net/manual/en/pdo.prepared-statements.php

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (?, ?)");
$stmt->bindParam(1, $name);
$stmt->bindParam(2, $value);

// insert one row
$name = 'one';
$value = 1;
$stmt->execute();

Aussi, ne pas oublier HTMLPurifier qui peut être utilisé pour rejeter toute invalide/suspect caractères.

...........

Edit: Sur la base des commentaires ci-dessous, j'ai besoin de poster ce lien (je l'ai fait avant désolé pour créer de la confusion)

mysql_real_escape_string() par rapport à des Déclarations Préparées à l'avance

Citant:

mysql_real_escape_string() enclins à le même genre de questions touchant à addslashes().

Chris Shiflett (Expert En Sécurité)

Answer 2

La réponse à votre question est Non. mysql_real_escape_string() n'est pas adapté à toutes les entrées utilisateur et mysql_real_escape_string() ne s'arrête pas toutes les sql injection. addslashes() est une autre fonction à utiliser en php, et il a le même problème.

code vulnérable:

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

poc exploiter:

http://localhost/sql_test.php?id=1 or sleep(500)

Le patch est à utiliser des guillemets autour de l'id:

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

Vraiment la meilleure approche est d'utiliser des requêtes paramétrées, dont un certain nombre de personnes avoir souligné. Aop fonctionne bien, adodb est un autre populaire de la bibliothèque pour php.

Si vous n'utiliser mysql_real_escape_string est devrait seulement être utilisé pour l'injection sql, et rien d'autre. Les vulnérabilités sont fortement tributaires de la façon dont les données sont utilisées. On devrait appliquer les mesures de sécurité sur une fonction par fonction. Et oui, XSS est un PROBLÈME TRÈS GRAVE. Pas de filtrage pour le html est une grave erreur qu'un pirate va utiliser pour pw3n vous. Veuillez lire le xss faq.

Answer 3

À la base de données, oui. Vous aurez envie de considérer adéquatement échapper / encodage des données de sortie.

Vous devriez également considérer la validation de la saisie à l'encontre de ce que vous attendez qu'elle soit.

Avez-vous envisagé d'utiliser des requêtes préparées? PHP offre de nombreuses façons d'interagir avec votre base de données. Dont la plupart sont mieux que les mysql_* les fonctions.

AOP, MDB2 et le MySQL Améliorée devrait vous obtenir a commencé.

Answer 4

Quelles situations?

Pour les requêtes SQL, c'est génial. (Les instructions préparées sont mieux je vote PDO pour cela - mais la fonction n'échappe à l'amende juste.) Pour le HTML et autres, ce n'est pas l'outil pour le travail - essayez un générique htmlspecialchars ou un outil plus précis comme HTML Purificateur.

À l'adresse edit: Le seul autre couche vous pouvez ajouter des données est valdation, par exemple, de confirmer que si vous mettez un nombre entier dans la base de données, et vous attendez un entier positif, vous renvoyer un message d'erreur à l'utilisateur de tenter de mettre dans un entier négatif. Aussi loin que l'intégrité des données est concerné, mysql_real_escape_string est le meilleur que vous avez pour échapper (même si encore une fois, les requêtes préparées sont un système de filtre qui évite de s'échapper entièrement).

Answer 5

mysql_real_escape_string() est utile pour prévenir uniquement les attaques par injection SQL. Cela ne vous aidera pas à empêcher les attaques de script entre sites. Pour cela, vous devez utiliser htmlspecialchars() juste avant la sortie des données initialement collectées à partir des entrées de l'utilisateur.