web-dev-qa-db-fra.com

PHP mysql_real_escape_string () -> Stripslashes () laissant plusieurs barres obliques

J'ai des problèmes d'échappement/de décapage des chaînes avec PHP/MySQL - il semble toujours y avoir des barres obliques redondantes.

Prenons la chaîne suivante comme exemple:

<span style="text-decoration:underline;">underline</span>


[.____] Lorsque vous ajoutez une chaîne à la base de données, je l'ai échappé avec mysql_real_escape_string() et les suivantes sont stockées dans la base de données ( [~ # ~] éditer [ ~ # ~] : vérifié cela en interrogeant la base de données directement avec l'application MySQL):

<span style=\\\"text-decoration:underline;\\\">underline</span>


[.____] Lorsque vous avez la lecture de la base de données, je passe la chaîne à travers stripslashes() et vous trouverez:

<span style=\"text-decoration:underline;\">underline</span>


[.____] Étant donné que les devis sont toujours échappés, il casse le HTML et le texte n'est pas souligné.

  1. Pourquoi mysql_real_escape_string() ajoute-t-il trois barres obliques et stripslashes() enlever deux barres obliques? Je m'attendrais à ce qu'ils ont tous deux ajouté/enlever une barre oblique.
  2. Comment puis-je empêcher cela de se produire?
  3. Est-ce que je m'approche de la bonne voie?
phpmysql-real-escape-stringstripslashes
18
teaforchris

Meilleure solution

Dans votre fichier php.ini, les chances sont que magic_quotes_gpc La directive est définie sur ON. Cela devrait être désactivé pour des raisons de sécurité. Si vous n'avez pas accès au fichier php.ini (par exemple, sur un hôte partagé), vous pouvez toujours accomplir la même directive à utiliser une directive .htaccess (en supposant qu'il s'agisse d'un serveur Apache).

Dans votre php.ini

magic_quotes_gpc Off

Dans un fichier .htaccess:

php_flag magic_quotes_gpc Off

Pourquoi cela arrive-t-il?

La raison pour laquelle cela se passe est due au cours suivant de la logique.

  1. Une chaîne qui a besoin de s'échapper est envoyée au serveur.
    • This is my string. It's awesome.
  2. Les citations magiques échappent à l'apostrophe avant de pouvoir atteindre votre code.
    • This is my string. It\'s awesome
  3. mysql_real_escape_string a maintenant deux caractères à échapper, la barre oblique inverse \\ ainsi que l'apostrophe \'.
    • This is my string. It\\\'s awesome
  4. Cette nouvelle chaîne super-échappée est stockée dans la base de données.
  5. Lorsque la chaîne est extraite de la base de données, elle est transmise à stripslashes. Cela supprime les deux échappées ajoutées à l'étape 3, mais étant donné que l'une des backslashes a été échappée stripslashes pense qu'il appartient. [.____]
    • This is my string. It\'s awesome

Ce problème peut vraiment sortir de la main lorsque vous soumettez ces chaînes à la base de données, à chaque fois que le nombre de barres anti-backslash multiplie.

Solution alternative

Une alternative rapide et facile serait de supprimer simplement les barres obliques ajoutées par magic_quotes Avant de passer la chaîne à mysql_real_escape_string.

$str = stripslashes($_POST['str']);
$str = mysql_real_escape_string($str);
81
tj111

Lorsque vous ajoutez une chaîne à la base de données, je l'ai échappé avec mysql_real_escape_string() _ et les suivantes sont stockées dans la base de données:

<span style=\\\"text-decoration:underline;\\\">underline</span>

Non ce n'est pas. Lorsque vous échappez à des chaînes dans une requête SQL, il s'agit uniquement de transporter les données de la requête. La base de données analyse la requête et stocke les données de la base de données, sans aucune barre oblique supplémentaire. Ainsi, lorsque vous récupérez les données de la base de données, vous devriez non NASESCAPIER. C'est une idée fausse commune.

Si vous constatez qu'il y a des baisses excessives dans la sortie, vous avez probablement des citations magiques activées. Les éteignez .

Éditer:

mysql> create table foo (bar text) ;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO foo (bar) VALUES ("<span style=\\\"text-decoration:underline;\\\">underline</span>");
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM foo;
+-------------------------------------------------------------+
| bar                                                         |
+-------------------------------------------------------------+
| <span style=\"text-decoration:underline;\">underline</span> | 
+-------------------------------------------------------------+
1 row in set (0.00 sec)

Comme vous pouvez le constater, la requête comporte un niveau de plus en évasion que les données apparaissent dans la base de données et, par conséquent, la manière dont il sort lors de l'interrogation. Dans votre cas, qu'est-ce que c'est probablement Se passe, est que vous avez des citations magiques activées, puis vous échappez à des cordes avant de les incorporer dans une requête. Cela conduit à une double évasion, altérant vos données. La solution appropriée consiste à continuer à échapper des cordes comme vous, mais éteignez les citations magiques. Et NE PAS Faites quelque chose sur les données car il sort de la base de données. Méfiez-vous que les données déjà dans le système doivent être nettoyées en premier.

3
troelskn

Si get_magic_quotes_gpc() est désactivé dans le serveur, alors seulement nous pouvons utiliser

$data= mysql_real_escape_string($_POST['data']);

si get_magic_quotes_gpc() est sur le serveur, nous devons utiliser

$data= mysql_real_escape_string(stripslashes($_POST['data']));

sinon ajoutez deux backslashes avec vos données.

Aussi une autre solution est que nous pouvons utiliser stripslashes($data) _ _ Tout en récupérant de la date de données si nous utilisons uniquement l'utilisation mysql_real_escape_string($_POST['data']);

1
sujay mondal