Est-il une fonction que je peux utiliser en Perl pour vérifier les entrées avant de les mettre dans une base MySQL? Je ne sais pas regex très bien, donc avant de me faire ma propre fonction je me demandais si il y avait déjà un fait.
Réponses
Trop de publicités?
La bonne façon de désinfecter les données pour l'insertion dans votre base de données est d'utiliser des espaces réservés pour toutes les variables à insérer dans la chaîne de requête. En d'autres termes, ne JAMAIS faire cela:
my $sql = "INSERT INTO foo (bar, baz) VALUES ( $bar, $baz )";
Au lieu de cela, utilisez ? espaces:
my $sql = "INSERT INTO foo (bar, baz) VALUES ( ?, ? )";
Et puis passer les variables qui doivent être remplacées lorsque vous exécutez la requête:
my $sth = $dbh->prepare( $sql );
$sth->execute( $bar, $baz );
Vous pouvez combiner ces opérations avec certains DBI des méthodes pratiques; le ci-dessus peut aussi s'écrire:
$dbh->do( $sql, undef, $bar, $baz );
Voir le DBI docs pour plus d'informations.
Dave Sherohman
Points
25122
Mineur (et, certes, pédant) addendum à la section "utilisation des espaces réservés" réponses: les requêtes Paramétrées ne sont pas, à proprement parler, de "désinfection". Ils ne modifient pas les données d'une quelconque manière à la rendre sécuritaire. Au lieu de cela, ils protègent contre les injections SQL par l'envoi de la structure de la requête (les commandes) et les données par des canaux distincts.
La raison je sens que cette distinction est importante est parce que le traitement de désinfection/citer/s'échapper de vos données et l'utilisation de requêtes paramétrées comme la même chose implique qu'ils sont interchangeables ou, au mieux, que les paramètres sont une meilleure façon de devis dangereux personnages, donc c'est pas grave si vous vous contentez de citer au lieu de prendre la peine de comprendre que l'espace réservé choses.
En vérité, ils sont complètement différents avec les techniques de complètement différents niveaux de fiabilité. Citant peut fournir une excellente protection contre les injections, mais il y a toujours le risque qu'un attaquant pourrait trouver quelques cas de coin qui va se casser ou se glisser à travers vos citant algorithme et de leur permettre d'effectuer une injection de code SQL. Les requêtes paramétrées, d'autre part, de fournir absolue de la protection contre les injections SQL. Parce que les commandes et les données sont envoyées séparément, il n'y a aucun moyen que le moteur de base de données peuvent être dupé dans l'exécution des données comme une commande.
Sauf si vous êtes dans le cas où votre langue ou le moteur de base de données ne vous permettra pas d'utiliser un paramètre dans votre requête, de ne jamais citer/escape/désinfecter la saisie de l'utilisateur en tant que protection contre les injections SQL. Toujours utiliser des requêtes paramétrées, pour ce but, si vous êtes en mesure de le faire.
Et l'indispensable lien: http://bobby-tables.com/ a exemples d'utilisation de requêtes paramétrées dans plusieurs langues différentes, y compris Perl.
codeholic
Points
2726
Dans de très rares cas, vous n'êtes pas en mesure d'utiliser des espaces réservés, comme décrit dans d'autres réponses. Mais même dans ces rares cas, vous ne devriez pas altérer les données par vous-même, car il fait une place pour un éventuel bug. Il est préférable d'utiliser DBI de l' quote et quote_identifier méthodes. Aussi, il rend votre code moins dépendants sur un SGBDR.
Avertissement. Ce qui suit est un mannequin d'exemple et n'est pas destiné à illustrer les très rares cas que j'ai mentionnés.
$dbh->do('INSERT INTO ' . $dbh->quote_identifier($table) . ' (id, name) VALUES '
'(NULL, ' . $dbh->quote($name) . ')');
Mikael S
Points
2973
Comment appelez-vous la base de données?
DBI en charge des déclarations préparées à l'aide des espaces réservés. Les deux DBIx::Class et Rose::DB::Objet désinfecter automatiquement les valeurs, si vous utilisez la fonction "rechercher" méthode fournie par chaque bibliothèque.
