web-dev-qa-db-fra.com

Quel est le meilleur moyen de désinfecter les données?

J'ai lu plusieurs sujets à ce sujet et différentes personnes ont des points de vue différents sur les meilleures pratiques.

En termes de WordPress, comment puis-je écrire des données dans la base de données de la manière la plus sûre?

Ceci est un insert que j'utilise maintenant:

$result = $wpdb->insert(
    $table_name , 
    array( 
        'arena'         => $galleryData['arena'],
        'year'          => substr( $galleryData['season'], 2 ),
        'copyright'     => $galleryData['copyright'],
        'description'   => $galleryData['description'],
        'path'          => $galleryData['path'],
        'fk_brand_id'   => $galleryData['brand']
    ), 
    array( '%s', '%d', '%s', '%s', '%s', '%d' )
);

Une autre façon d’insérer des données est la suivante:

$sanitized_sql = $wpdb->prepare( "
    INSERT INTO my_plugin_table 
    SET 
        field1 = %1$d,
        field2 = %2$s,
        field3 = %3$s’,
        32, 
        'Aaron Brazell',
        'Washington, D.C'
" );
$wpdb->query( $sanitized_sql );

Dois-je toujours nettoyer les données à l’aide de wp_kses() ou mysql_real_escape_string() ?

Je ne comprends pas quelle méthode est la meilleure pour écrire des données en toute sécurité dans la base de données. J'ai trouvé une réponse utile sur Stack Overflow .

Alors, devrais-je ou ne devrais-je pas nettoyer les données avant la saisie?

7
Steven

Non, la désinfection est déjà faite. Eh bien, le mysql_real_escape_string est terminé, il est considéré comme une mauvaise forme pour filtrer le code HTML en entrée. Personnellement, je pense que le faire en sortie est un peu une violation à sec. Si vous l'avez fait dans WordPress, je pense que quelque part ailleurs le fera à nouveau, ce qui entraînera un double encodage des entités HTML.

De plus, wpdb :: insert est fondamentalement juste un wrapper pour wpdb :: prepare.

1
Backie

Notez que stocker les données en toute sécurité est différent de safe data . Par exemple, le code JavaScript peut être totalement inoffensif dans le contexte de la sécurité de la base de données, mais cauchemard dans le contexte du front-end.

Il n’existe pas d’approche globale. C’est pourquoi WordPress propose une quantité considérable de fonctions connexes .

Vous devez considérer:

  1. Quelles données sont.
  2. D'où ça vient.
  3. Comment cela va-t-il être utilisé?.
4
Rarst