[RESOLU] Pourquoi n'est-il pas bon de stocker du HTML dans une BDD ?

Bonjour,

Je tente de mettre au point une console d'administration pour mon site, un genre de CMS fait maison, très simple, parfaitement adapté à mes besoins et à la nature de mon site.

Or je lis aussi ici où là qu'il n'est pas du tout recommandé de stocker du HTML dans une BDD. Voici à ce propos un exemple lu dans un forum :

"- En second lieux, se poser la question de savoir s'il est vraiment bon de stocker du HTML dans sa base de donnée. Un petit exemple très amusant : http : //fr.thedailywtf.com/Articles/Mentors,-the-Freshmaker-(T).aspx.
- Enfin, si tu veux toujours stocker ton HTML dans ta BDD, tu devrais soit utiliser html_entity_decode() lors de la récupération de tes donnés OU remplacer ton htmlentities() par un mysql_real_escape_string()"

Voici un autre exemple sur un autre forum :

"Même si, normalement, on ne stocke jamais en BDD du code HTML, la fonction html_entity_decode te sera sûrement utile."

Ces deux exemples suffisent.

Mais moi, ça me turlupine, ça me donne des cauchemars... En effet, j'ai beau tourner la chose dans tous les sens, je ne vois pas comment :

1) on peut mettre en oeuvre un système de gestion de contenu sans mettre du HTML en BDD. D'ailleurs les CMS que j'ai examinés (CMS Made Simple, Joomla!, etc.) stockent bien du HTML en BDD, le code brut même, avec les balises et tout et tout ! Et les champs de la BDD où le contenu est stocké sont souvent le champ TEXT...

2) un site comme Alsacreations par exemple peut fonctionner sans stocker d'une manière ou d'une autre du html en BDD. Par exemple, le message que je suis actuellement en train d'écrire sera évidemment stocké en BDD. Or il comporte une mise en forme, les paragraphes que j'écris par exemple, donc au moins des balises <p></p> ! Que dire alors si je mets une partie du texte en gras, en italique, etc., et si j'y insère un lien. Tout cela se traduit évidemment par du HTML qui sera stocké en BDD quand j'aurai cliqué sur le bouton pour poster mon message, non ?

Qu'ils ne soient pas stockés sous une forme brute mais convertis avec des fonctions du genre htmlentities() ou htmlspecialchars(), OK, là n'est pas ce qui me gêne. Ce qui me tracasse, c'est l'idée suivante qui ressort à chaque fois un peu partout : "Normalement, on ne stocke pas du HTML; mais si néanmoins on veut passer outre cette recommandation et stocker quand-même, alors il faut utiliser htmlentities() etc., ce qui est un moindre mal".

C'est comme s'il existait une alternative au fait de stocker du contenu HTML (transformé ou pas) en BDD. Moi je ne vois pas, il y a un mystère que je vous prie de bien vouloir m'aider à résoudre...
Modifié par somdina (07 Dec 2010 - 21:42)

Bonjour,

- ce forum utilise du BBCode et pas du HTML ; exemple : [ b]du gras[ /b] (sans les espaces ça donne bien du gras)
D'autres formats existent décrivant non pas du code HTML mais le sens que l'on veut donner aux mots du texte, comme la syntaxe SPIP, Markdown, Textile, etc
Ce n'est qu'au moment de l'affichage que le texte est converti en HTML, selon les contraintes du site. Par exemple est-ce que le titre principal d'une actualité c'est h2 ou h3 ou h4 ? Ca peut être h3 sur la page d'accueil et h2 sur la page où on va lire l'actualité dans son intégralité. Quel masochiste irait stocker son actu avec 2 codes HTML différents, avec obligation de modifier à 2 endroits à chaque modification du texte ?
Et si dans 2 ans je change les gabarits du site et que ce qui était un h3 est maintenant un h2, les classes a, b et c deviennent d, e et e (plus de différence graphiques entre 2 choses au sens différent) puis qu'à nouveau je veux styler cette classe e de 2 manières différentes selon que c'est l'ancien b ou l'ancien c mais que j'ai modifié tout mon code HTML pensant ne plus jamais différencier les 2 ?

Les fonctions PHP dont tu parles sont extrêmement importantes : c'est ton seul rempart contre une attaque de ton site par des scripts malicieux. Injection SQL, XSS, CSRF, etc les articles de Wikipedia seront plus clairs que moi.
En résumé est-ce que tu permets à un inconnu de rajouter son code Javascript dans ta page alors que tu es connecté en tant qu'administrateur à ton site ou un autre code dans les pages affichées par tous tes visiteurs ?

edit: mandatory XKCD cartoon
Modifié par Felipe (06 Dec 2010 - 21:24)

Felipe a écrit :

- ce forum utilise du BBCode et pas du HTML ; exemple : [ b]du gras[ /b] (sans les espaces ça donne bien du gras)
D'autres formats existent décrivant non pas du code HTML mais le sens que l'on veut donner aux mots du texte, comme la syntaxe SPIP, Markdown, Textile, etc
Ce n'est qu'au moment de l'affichage que le texte est converti en HTML, selon les contraintes du site.

Merci. Pour mettre des mots en gras ou en italique dans mon message, j'ai utilisé évidemment ces balises BBCode, donc je sais que le texte n'est pas stocké directement avec des balises HTML. Comme je l'ai précisé, là n'est pas vraiment le sens de ma question et ce qui me tracasse.

Felipe a écrit :

En résumé est-ce que tu permets à un inconnu de rajouter son code Javascript dans ta page alors que tu es connecté en tant qu'administrateur à ton site ou un autre code dans les pages affichées par tous tes visiteurs ?

Merci aussi pour tes explications concernant la sécurité, en particulier quand le code stocké provient d'un utilisateur, via un formulaire comme celui dans lequel j'écris, avec les risques d'une éventuelle injection du code Javascript.

Mais ma question n'est pas : "Pourquoi n'est-il pas recommandé de stocker en BDD du html à l'état BRUT ?" mais en fait : "Pourquoi n'est-il pas recommandé de stocker en BDD du html, à l'état BRUT ou PAS, sous forme de BBCode ou PAS ?"

Car c'est ce que semblent dire le genre de propos que je rapporte. Ils ne s'inscrivent apparemment pas dans une problématique de sécurité (que je comprends très bien et à laquelle je suis sensibilisé) mais dans une problématique de bonne pratique de la programmation, comme cela ressort clairement des propos suivants que j'ai mentionnés :

"- En second lieux, se poser la question de savoir s'il est vraiment bon de stocker du HTML dans sa base de donnée. Un petit exemple très amusant : http : //fr.thedailywtf.com/Articles/Mentors,-the-Freshmaker-(T).aspx."

C'est là où je ne comprends plus rien, car pour moi il y a une grande différence entre dire :

"Ne mettez pas de code html BRUT dans votre BDD sans prendre toutes les précautions de sécurité nécessaire."

et dire :

"Ne mettez pas de code html dans votre BDD."

Dans le premier cas, cela signifie que c'est inévitable de stocker du html en BDD, mais seulement il ne faut pas stocker du brut, mais il faut le travailler au stockage comme à la récupération. Et alors, si mon site n'est pas un forum ou ne stocke pas des informations venant de l'extérieur (l'utilisateur) ou pouvant transiter par l'url par exemple, mais expose simplement les articles que j'écris moi-même et dont les matières sont puisées dans la BDD, je n'ai pas à m'inquiéter de ces problématiques, qui restent juste des recommandations de sécurité.

Dans le second cas, c'est une toute autre affaire : sécurité ou pas, BBCode ou pas, html_entity_decode ou pas, il ne faut pas mettre du html en BDD, c'est une mauvaise manière de programmer, d'utiliser la BDD, de stocker les données, etc. Il ne faut le faire qu'en cas de force majeur, mais alors en utilisant BBCode , html_entity_decode, etc. Sinon, il faut procéder autrement. Et c'est là où je ne vois pas comment on peut faire autrement.

Je ne sais pas si je me fais bien comprendre...
Modifié par somdina (06 Dec 2010 - 22:17)

salut... et oula tu te prend la tête !!!

En clair... Il ne FAUT PAS stocker du HTML en BDD sans SECURISER un maximum dans le cas d'une injection libre...

SInon on s'en fout on stocke ce qu'on veut en BDD, même des images avec un binary...

Le problème vient bien de la sécurité...mais évidemment tout le monde sait qu'on ne stocke pas directement et en brut ce qu'un internaute va écrire dans un textarea libre d'accès à tout un chacun !! Sauf et encore que, avec une sécurité maximum d'injection... voir html entities et autres fonctions du meme genre...

Dans ton cas c'est toi qui injecte via une admin... si ton admin est bien sécurisée, alors pas de soucis... tu peux stocker tout ton site en BDD...

j'esère avoir apporter un peu de lumière à ton esprit....

pchlj a écrit :
salut... et oula tu te prend la tête !!!

En clair... Il ne FAUT PAS stocker du HTML en BDD sans SECURISER un maximum dans le cas d'une injection libre...

SInon on s'en fout on stocke ce qu'on veut en BDD, même des images avec un binary...

Le problème vient bien de la sécurité...

(...)

Dans ton cas c'est toi qui injecte via une admin... si ton admin est bien sécurisée, alors pas de soucis... tu peux stocker tout ton site en BDD...

j'esère avoir apporter un peu de lumière à ton esprit....

Je suis content de te l'entendre dire, car c'est bien ce que je me disais aussi : il n'y a que les raisons de sécurité qui peuvent dicter de ne pas mettre du html BRUT en BDD.

C'est pour cela que je ne comprenais ce genre de propos que j'ai mis en évidence. Comme quoi, des choses mal dites peuvent induire en erreur si on n'y réfléchit pas, ce qui est le cas ici. Elles peuvent même constituer une vraie INTOX car on s'installe dans de fausses idées, on se ferme des portes inutilement, on se complique la vie à chercher des contours et des détours pour éviter un problème qui n'est pas en réalité où l'on s'est fait mettre dans la tête qu'il est... Merci à toi.

Et maintenant, si tu peux m'en dire davantage sur la problématique d'auto-injection via mon admin, je suis preneur. Tu parles de mes propres erreurs ou d'autre chose ? Je comprends qu'on puisse m'être nuisible si l'on accède à mon admin (pour cause de dossiers ou de fichiers non protégés ou de mot de passe non sécurisé par exemple). Sinon, à part ça, je ne comprends comment je peux m'injecter moi-même. Explications, s'il te plaît.

Bonjour,

Tout dépend du contexte. Si tu développes un site où les utilisateurs peuvent gérer le contenu uniquement via du BBCode, comme c'est souvent le cas sur les forums, il faut stocker dans la base de données le BBCode. C'est à l'affichage que l'application doit convertir le BBCode en code HTML/CSS. Dans un tel contexte, la recommandation est valable et c'est sans doute dans ce contexte précis que la recommandation a été faite.

Dans un autre contexte où les utilisateurs peuvent gérer le contenu via un éditeur HTML comme TinyMCE et CKEditor, il est pertinent de stocker le contenu HTML en base de données. Ce serait contre productif de ne pas le faire.

Tel que mentionné, que ce soit du texte, du HTML ou du BBCode qui est stocké dans la base de données, le plus important est de respecter les normes de sécurité contre les injections.

Finalement, même si c'était sans doute lancé à la blague, il vaut mieux éviter de stocker les images directement en base de données.

Tony Monast a écrit :

Tout dépend du contexte. Si tu développes un site où les utilisateurs peuvent gérer le contenu uniquement via du BBCode, comme c'est souvent le cas sur les forums, il faut stocker dans la base de données le BBCode.

(...)

Dans un autre contexte où les utilisateurs peuvent gérer le contenu via un éditeur HTML comme TinyMCE et CKEditor, il est pertinent de stocker le contenu HTML en base de données. Ce serait contre productif de ne pas le faire.

Aah ! voilà quelque chose qui ajoute de la lumière à celle que je viens d'avoir. Merci.

Tony Monast a écrit :

C'est à l'affichage que l'application doit convertir le BBCode en code HTML/CSS. Dans un tel contexte, la recommandation est valable et c'est sans doute dans ce contexte précis que la recommandation a été faite.

Si t'as un petit moment, tu peux jeter un coup d'oeil sur ce lien : http : //fr.thedailywtf.com/Articles/Mentors,-the-Freshmaker-(T).aspx.

Je t'assure qu'à travers l'exemple que le gars mentionne, outre la grossière erreur de stocker les mots de passe dans un fichier à la racine du site, il semble bel et bien vouloir démontrer que stocker du html en BDD pose de sérieux problèmes de maintenance, d'évolutivité, etc.

Tony Monast a écrit :

Finalement, même si c'était sans doute lancé à la blague, il vaut mieux éviter de stocker les images directement en base de données.

Excuse-moi, voilà justement le genre de propos où je me dis : une petite phrase ou deux pour expliquer sommairement pourquoi il vaut mieux l'éviter serait la bienvenue...

Raison de sécurité aussi ? Raison de volume ou d'encombrement de la base ? Problème de performance de la base ? Etc.

C'est pas ma faute si j'ai deux bras gauches et un seul neurone . Si on m'explique un peu, comme tu viens de le faire pour le code HTML, j'arrive à comprendre... Sinon, sans autre explication, mon cerveau a très facilement tendance à s'inventer ses raisons à lui, qui souvent ne sont pas les bonnes...
Modifié par somdina (07 Dec 2010 - 01:12)

Pour le stockage des images en base de données, ce n'est pas recommandé pour les raisons suivantes :

- Encombre la base de données inutilement, car dans la grande majorité des applications, il est plus raisonnable de n'y stocker que le nom ou le chemin du fichier
- Peut ralentir les performances
- Difficile à maintenir : c'est beaucoup plus facile consulter les fichiers directement dans un dossier plutôt qu'en base de données, et encore plus facile de modifier/manipuler un fichier lorsque c'est nécessaire.

somdina a écrit :
Si t'as un petit moment, tu peux jeter un coup d'oeil sur ce lien : http : //fr.thedailywtf.com/Articles/Mentors,-the-Freshmaker-(T).aspx.

Je t'assure qu'à travers l'exemple que le gars mentionne, outre la grossière erreur de stocker les mots de passe dans un fichier à la racine du site, il semble bel et bien vouloir démontrer que stocker du html en BDD pose de sérieux problèmes de maintenance, d'évolutivité, etc.

Je crois que tu as mal interprété l'article. L'auteur de l'article est sarcastique lorsqu'il trouve que mettre les mots de passe en clair à la racine du site est une bonne idée. Pour ce qui est du stockage dans la base de données, il ne parle pas du HTML, mais bien du formatage (CSS). Ce qui est important de faire est d'éviter au maximum, dans la mesure du possible, de stocker du code CSS dans la base de données, afin de permettre de modifier la mise en page sans être obligé d'éditer tous les enregistrements dans la base de données. Par exemple, au lieu de stocker en base de données ceci :

<h2 style="color:blue;font-weight:bold;font-size:220%">Mon titre bleu et gras</h2>

Il faut plutôt stocker ceci :

<h2>Mon titre bleu et gras</h2>

et appliquer les styles requis via une feuille de style externe.

h2 {
color:blue;
font-weight:bold;
font-size:220%;
}

Modifié par Tony Monast (07 Dec 2010 - 01:46)

Pour enfoncer le clou:
Tu dois filtrer ce qui entre et ce qui sort de ton script/db.
Si tu autorises du html (parce que tu urilises un éditeur riche tel que tinyMCE), il te faut procéder par liste blanche : une série de tags et éléments autorisés. Ce qui n'est pas autorisé est rejeté (ou converti).
Par ailleurs, comme le suggère Felipe, tu peux stocker le html sous une forme alternative, telle que markdown.

Ces recommandations sont valables pour un cms, mais encore plus pour les forums, blogs etc ou tout internaute peut accéder à des formulaires divers.

Si la sécurité te préoccupe, le bouquin de Seguy/Gamache est un bon début, très pragmatique.

Tony Monast a écrit :
Pour le stockage des images en base de données, ce n'est pas recommandé pour les raisons suivantes :

- Encombre la base de données inutilement, car dans la grande majorité des applications, il est plus raisonnable de n'y stocker que le nom ou le chemin du fichier
- Peut ralentir les performances
- Difficile à maintenir : c'est beaucoup plus facile consulter les fichiers directement dans un dossier plutôt qu'en base de données, et encore plus facile de modifier/manipuler un fichier lorsque c'est nécessaire.

Merci. C'est très clair.

Tony Monast a écrit :

Je crois que tu as mal interprété l'article. L'auteur (...) ne parle pas du HTML, mais bien du formatage (CSS).

Je dirai simplement que l'erreur d'interprétation a été très fortement induite par ce propos dans un forum qui renvoyait à cet article en guise d'exemple ou d'illustration (lien du propos : http : // www .phpcs.com/forum/sujet-AFFICHER-CODE-HTML-PROVENANT-BDD-MYSQL_1266644.aspx). Je cite pour la troisième et dernière fois... :

" - En second lieux, se poser la question de savoir s'il est vraiment bon de stocker du HTML dans sa base de donnée. Un petit exemple très amusant : http : //fr.thedailywtf.com/Articles/Mentors,-the-Freshmaker-(T).aspx
- Enfin, si tu veux toujours stocker ton HTML dans ta BDD, tu devrais soit utiliser html_entity_decode()..."

Comme le montre le titre, le sujet de ce forum portait effectivement sur l'enregistrement du code HTML dans une BDD et sa récupération et non pas sur le formatage CSS.

L'intervenant qui répondait à la question posée voulait (peut-être, car on n'est pas dans son esprit) simplement dire : "Il ne faut pas stocker du HTML en BDD sans avoir fait ceci ou cela, pour des raisons de sécurité."

Mais avouons que telles que les choses sont dites (en particulier les termes que j'ai mis en relief) cela revient en gros à dire : "Ce n'est pas bon de mettre du HTML en BDD, à la rigueur et en cas de force majeur, il faut le faire en utilisant les fonctions d'échappement..."

La problématique CSS en BDD est une chose, et la problématique de la SECURITE HTML en BDD (le vrai problème, comme vous me l'avez tous bien expliqué) en est une autre.

M'enfin, c'est maintenant clarifié dans mon esprit, et c'est ce qui compte. Merci.
Modifié par somdina (07 Dec 2010 - 20:43)

Bonjour,

L'intervenant en question a peut-être aussi mal interprété l'article en question en mixant HTML et CSS. Après tout, ce n'est pas faux non plus, l'attribut style d'un élément est bien du HTML. Par contre, ce qu'il y a dans cet attribut est plutôt du CSS.

Tel que je l'ai mentionné plus tôt, la recommandation que cet intervenant a faite a peut-être été faite dans un contexte particulier ou selon son expérience personnelle. Il a peut-être toujours utilisé une syntaxe comme du BBCode et n'a jamais eu besoin d'utiliser un éditeur HTML comme TinyMCE. Le mieux serait de le contacter pour éclaircir tout ça, mais je crois qu'on a quand même fait le tour de la question...
Modifié par Tony Monast (07 Dec 2010 - 20:44)

Tony Monast a écrit :
Je crois qu'on a quand même fait le tour de la question...

Exact, et c'est ce que je dis aussi. Au fait comment marque-t-on ici qu'un sujet est résolu ?

Tu dois t'idenfier d'abord, puis aller éditer ton premier message pour ajouter le mot [Résolu] au début du titre.

Tony Monast a écrit :
Tu dois t'idenfier d'abord, puis aller éditer ton premier message pour ajouter le mot [Résolu] au début du titre.

Ah d'accord. Merci.