Échappement des données utilisateur, sans guillemets magiques

Question

Je regarde comment échapper correctement aux données provenant du monde extérieur avant qu'elles ne soient utilisées pour le contrôle des applications, le stockage, la logique, etc. Ce genre de chose.

Évidemment, avec la directive magique citations, bientôt obsolète dans PHP 5.3.0+ et supprimée dans PHP 6, cela devient encore plus urgent, pour ceux qui cherchent à mettre à niveau et à utiliser les nouvelles fonctionnalités linguistiques tout en conservant le code hérité (don ' t on l’aime ..).

Cependant, une chose que je n’ai pas vue est beaucoup de discussions sur la théorie / les meilleures pratiques concernant la procédure à suivre une fois que vous avez protégé vos données - par exemple, stocker avec ou sans barres obliques? Personnellement, je pense que garder les données échappées dans la base de données est une mauvaise chose, mais je veux entendre la discussion et lire quelques études de cas de préférence.

Quelques liens du manuel PHP juste pour référence:

Manuel PHP - mysql_real_escape_string

Manuel PHP - htmlspecialchars

etc. etc.

Des conseils?

Answer 1

Regardez les déclarations préparées. Je sais que dans mysql cela fonctionne très bien et est une forme sécurisée d’obtention de données dans votre base de données. Il présente également quelques avantages en termes de performances.

http://dev.mysql.com/tech -resources / articles / 4.1 / prepare-statement.html

J'ai d'autres ressources si cela vous intéresse.

J'espère que c'est ce que vous recherchez, tc.

Modifier:

Une chose que je peux ajouter est d’utiliser des filtres en combinaison avec des instructions préparées. Par exemple, pour vérifier si la valeur est une aiguille, vous utilisez FILTER_SANITIZE_STRING, ou pour le courrier électronique, vous utilisez FILTER_SANITIZE_EMAIL.

Ceci économise une certaine quantité de code et fonctionne très bien. Vous pouvez toujours vérifier les données en utilisant vos propres méthodes par la suite, mais vous pouvez utiliser de nombreux filtres.

Answer 2

• Utilisez la méthode correcte pour échapper des données lors de l'exécution de requêtes: mysql_real_escape_string, requêtes préparées, etc ...

• Stocker les données dans la base de données non modifiées

• Utilisez la méthode correcte pour échapper des données en sortie: htmlspecialchars, etc.

Answer 3

Pour le travail sur la base de données, vérifiez les requêtes paramétrées et les instructions préparées. AOP et mysqli sont bons pour cela.

Htmlspecialchars est le bon outil pour afficher du texte en html documents.

Et, comme vous l'avez mentionné php 5.3, vous avez accès aux fonctions de filtrage indispensables lors du traitement des données utilisateur.

Answer 4

Pour les insertions de base de données, la solution consiste à utiliser les variables de liaison .

En général, chaque fois que vous vous retrouvez en train d'échapper à quelque chose (argument d'une commande shell, élément de commande db, html fourni par l'utilisateur, etc.), cela indique que vous n'utilisez pas le bon appel de fonction (par exemple, en utilisant < code> system lorsque vous pouvez utiliser une forme multi-argument de exec ) ou que votre infrastructure est déficiente. L’approche standard pour travailler dans un cadre déficient consiste à l’améliorer pour que vous puissiez revenir à ne plus penser à la citation.

Penser aux niveaux d’évasion et de citation peut être amusant, mais si vous appréciez vraiment cela, jouez avec Tcl pendant votre temps libre. Pour un vrai travail, vous ne devriez pas songer à citer, sauf si vous concevez une bibliothèque destinée à être utilisée par d'autres personnes. (Et vous devez documenter très soigneusement le type de citation que vous faites et ne faites pas.)

Answer 5

C'est simple. TOUTES LES données entrantes doivent être traitées via mysql_real_escape_string () avant de les insérer dans la base de données. Si vous savez par exemple que quelque chose doit être un entier, définissez-le sur un entier avant de l'insérer, etc. N'oubliez pas que c'est simplement pour arrêter l'injection SQL. XSS et la validation des données sont différentes.

Si vous voulez que quelque chose soit un email, vous devez évidemment le valider avant de l'insérer dans la base de données.

htmlentities () supprime les données, ce qui signifie qu'elles modifient . Je pense que vous devriez toujours stocker les données brutes dans la base de données et lorsque vous saisissez ces données, choisissez comment vous souhaitez les assainir.

J'aime utiliser la fonction suivante en tant que "wrapper". pour la fonction mysql_real_escape_string () .

function someFunction( $value )
{
    if ( is_int( $value ) || is_float( $value ) ) {
        return $value;
    }
    return "'" . mysql_real_escape_string( (string) $value ) . "'";
}

Si la valeur est un nombre à virgule flottante ou un entier, l'exécution de mysql_real_escape_string" rel="nofollow noreferrer"> mysql_real_escape_string () . La raison pour laquelle j'ai converti la valeur en chaîne avant de la transmettre à mysql_real_escape_string () , est parfois due à la valeur pourrait ne pas être une chaîne.

Exemple de valeur n'étant pas une chaîne:

http: //localhost/test.php? hello [] = test

Dans test.php, vous exécutez mysql_real_escape_string () sur $ _GET ['hello'] dans l'attente bonjour pour être une chaîne. Eh bien, puisque la personne a défini la valeur sur un tableau, cela provoquera un avis puisque bonjour n'est pas une chaîne.