2010-07-16 4 views
0

Je me demandais juste si je devais encoder toutes les données avant de les mettre dans la base de données ou de les afficher à l'utilisateur? Ou les deux.Html Encode lorsque les données sont entrées? Ou produit ou les deux?

En ce moment je le fais quand je montre à l'utilisateur. J'utilise asp.net mvc 2.0 donc je fais juste tout simplement <%: %> ce que l'encodage pour moi.

Je ne suis pas sûr avec les deux mais il pourrait être un peu extrême pour le faire à des moments.

Aussi, j'ai vraiment juste à faire attention à la chaîne entrée par l'utilisateur non?

Comme je viens de rencontrer un problème où l'un de mes plugins ne pouvait pas, pour une raison quelconque, comprendre comment trier les dates si la date était encodée en HTML.

Je viens de le faire encoder sans y penser. Maintenant que quelqu'un me l'a indiqué, cela n'a pas de sens de faire cela puisque je reçois la date directement dans la base de données et dans la base de données, elle est stockée en tant que datetime. Donc, ne peut pas vraiment stocker javascript là-bas.

Je suis donc je devine vraiment ne pas avoir à les encoder (me corriger si je me trompe)

int, bit (bools), dataetimes, décimaux types s'il stockés dans la base de données de cette façon.

Je pourrais encore les encoder juste pour le diable si cela n'effectue aucun de mes plugins mais il est bon de savoir que je n'ai probablement pas à le faire.

+0

habituellement vous 'obtenez' les données quand elles ont déjà été décodées, vous les avez mises dans la base de données (ou autre) décodée, et la syntaxe <%: %>, comme vous l'avez dit, gérera l'encodage au moment de l'affichage. Grâce à cette syntaxe, vous ne devriez pas avoir à vous soucier de l'encodage/décodage ailleurs (au moins dans la grande majorité des cas) –

Répondre

1

Dans la plupart des cas, vous ne devriez pas avoir à encoder des données HTML lorsque vous les stockez dans votre base de données. Comme vous l'avez noté vous-même, pour la plupart des types de données (ints, dates, etc.), il est préférable (c'est-à-dire plus performant, fonctionne avec d'autres systèmes, etc.) de le sauvegarder sans être codé.

Le cas dont vous devez vous préoccuper concerne les chaînes provenant d'une source externe (comme l'utilisateur final). Même dans ce cas, il devrait suffire de stocker les données non codées et d'utiliser <%: ... %> pour coder une fois les données renvoyées à un navigateur. Vous ne devriez envisager de coder la chaîne que si elle provient d'un contrôle utilisateur activé par le balisage (comme l'éditeur de texte TinyMCE ou quelque chose de similaire).

Toujours veiller à vous protéger contre les attaques par injection SQL. Vous devez vérifier qu'un élément de données destiné à représenter une date est en réalité une date avant que vous ne l'envoyiez à votre base de données.

+0

Ya tinyMCE est une exception à ma règle. Je ne peux pas le coder html à l'utilisateur (par défaut le but de celui-ci). Donc, avant de l'insérer dans ma base de données, j'utilise une liste blanche et une bibliothèque XSS pour vérifier si tout est sûr. Comme avec une attaque par injection SQl j'utilise linq to sql donc tout doit être un objet donc je dois convertir la date du formulaire en datetime et si elle ne peut pas l'analyser en datetime, ce n'est pas un datetime. – chobo2

Questions connexes