2010-09-14 8 views
1

Est-ce une idée bonne ou stupide d'assainir toutes les données qui pourraient être sqljected? J'ai écrit une fonction qui devrait le faire, mais je ne l'ai jamais vu faire et je me demandais si c'était une mauvaise idée. La fonction que j'ai écrite:Fonction PHP pour assainir toutes les données

function sanitizeData() 
{ 
    $_SERVER['HTTP_USER_AGENT'] = mysql_real_escape_string($_SERVER['HTTP_USER_AGENT']); 
    foreach(array_keys($_COOKIE) as $key) 
    { 
      $_COOKIE[$key] = mysql_real_escape_string($_COOKIE[$key]); 
    } 
    foreach(array_keys($_POST) as $key) 
    { 
      $_POST[$key] = mysql_real_escape_string($_POST[$key]); 
    }  
    foreach(array_keys($_GET) as $key) 
    { 
      $_GET[$key] = mysql_real_escape_string($_GET[$key]); 
    } 
} 
+0

Comment est-ce différent de citations magiques, que tout le monde a un problème? Ne fais pas ça. –

+0

Vous ne devez jamais écraser des superglobales. Vous pouvez, mais cela conduit à des failles de sécurité dans le passé (bugs internes PHP) et n'est pas recommandé. –

Répondre

6

Une mauvaise idée; c'est fondamentalement une autre version des magic_quotes obsolètes. La plupart de ces données ne finiront probablement pas dans la base de données, donc vous finirez par échapper inutilement, et potentiellement double-échapper.

Utilisez à la place des instructions préparées si nécessaire. Regardez mysqli_stmt (partie de mysqli) et PDOStatement (partie de PDO).

+1

+1 - Je ne comprends pas pourquoi tant de gens trouvent l'injection SQL compliquée - l'utilisation d'instructions préparées bloque toute cette classe d'attaques (pas que votre application soit sécurisée juste parce qu'elle ne peut pas être injectée en SQL). –

+0

bien merci. – Lienau

+0

@Billy pas entièrement. les identifiants ne peuvent pas être paramétrés. Cela vaut la peine de le garder à l'esprit. –

0

Il est également très important de comprendre que mysql_real_escape_string ne désinfecte rien.
En appliquant cette fonction, vous ne sécurisez pas les données. C'est un malentendu très répandu.
Cette fonction échappe simplement aux délimiteurs de chaîne. Donc, cela ne fonctionne que pour les chaînes, les citations délimitées. Ainsi, sanitization réel pourrait être que comme ceci:

$_GET[$key] = "'".mysql_real_escape_string($_GET[$key])."'"; 

Et même celui-ci est suffit pas.

Mais comme Matt l'a déjà mentionné, ce serait une très mauvaise pratique. Et plus encore: en fait, non seulement les données d'entrée doivent être correctement formatées/paramétrées. C'est la fonction de base de données, pas une entrée de l'utilisateur! Cela n'a rien à voir avec l'entrée de l'utilisateur. Certaines données peuvent provenir non pas d'une entrée de l'utilisateur, mais d'un fichier ou d'une autre requête ou d'un service - tout devrait être correctement formaté. C'est très important à comprendre.

Vous utilisez également une méthode impaire pour itérer des tableaux.
celui-ci est plus fréquent:

foreach($_GET as $key => $value) 
{ 
     $_GET[$key] = mysql_real_escape_string($value); 
} 
+0

Eh bien, il fait un peu plus - il * fait * des choses comme changer NULL en \ 0, des sauts de ligne en \ n, etc. Si c'était juste échapper des guillemets alors il n'y aurait pas besoin parce que vous pourriez juste utilisez une chaîne replace ou addslashes. (Mais vous ne devriez jamais utiliser string remplacer ou addslashes dans le code réel) –

+0

@Billy en fait pour remplacer uniquement les guillemets et un backslash lui-même est suffisant pour la plupart des cas :) Il y avait un gars qui a demandé de casser un échappement pour les données encodées en utf8, beaucoup ont essayé, mais pas de chance.Si vous connaissez un moyen ce serait génial. Mais peu importe, de toute façon. Mon point de vue est différent: échapper seul n'aide en rien –

Questions connexes