Verification des balises et attributs (un strip_tags avance)
4 réponses
Sebastien
Bonjour,
Pour une fois le sujet n'est peut-être pas assez explicatif donc je précise.
Pour différentes interfaces on a souvent besoin d'autoriser un peu de
HTML dans les entrées utilisateur mais strip_tags ne permet pas de
vérifier le contenu des tags autorisés (attributs et valeurs).
Donc je recherche un script qui permet de parser une chaîne en
supprimant tous les tags sauf ceux qui sont autorisés, mais dans ces
dernier qui limite également pour chacun les attributs autorisés et si
possible leur valeurs (ou type).
L'idéal est d'avoir un tableau PHP à plusieurs dimensions où sont
stockés tous ces paramètres et de la passer en argument à la fonction...
J'ai regardé les fonctions de WordPress mais c'est très compliqué (pour
moi, donc vous voyez en même temps mon niveau). Je pense que je peux
comprendre la logique mais quant à récupérer vraiment ce qui est utile,
je trouve que tout est imbriqué avec d'autres foncitons dont je n'ai pas
besoin.
Bonus points pour une méthode qui permet de valider le codage des
caractères (je dis bien codage et pas jeu de caractères) et la
conformité à HTML 4.O1 (avec un DOCTYPE strict).
Bref je suis à l'écoute des suggestions, c'est peut-être plus simple que
je ne l'imagine.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John GALLET
Bonour,
Pour différentes interfaces on a souvent besoin d'autoriser un peu de HTML dans les entrées utilisateur mais strip_tags ne permet pas de vérifier le contenu des tags autorisés (attributs et valeurs).
Malheureusement, oui.
Donc je recherche un script qui permet de parser une chaîne en supprimant tous les tags sauf ceux qui sont autorisés,
Jusqu'ici, strip_tags suffit. La première partie du boulot est faite, reste à aller vérifier les attributs.
mais dans ces dernier qui limite également pour chacun les attributs autorisés et si possible leur valeurs (ou type). Là, il faut le faire.
Bref je suis à l'écoute des suggestions, c'est peut-être plus simple que je ne l'imagine. Des exemples d'attaques à contrer sont disponibles sur
http://ha.ckers.org/xss.html
Pas évident de trouver une méthode simple et idiot-proof pour différencier un contenu d'attribut valide d'une injection. Moi je voterais pour n'autoriser que les tags bruts sans attributs, ou je gèrerais ça en tant que liste fermée d'attributs autorisés par tag (aussi bien le nom de l'attribut que son contenu). Dans tous les cas, il va falloir parser allègrement et ça va être lourd.
Je pense que des réponses plus éclairées seraient disponibles dans les archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à la solution d'une espèce de méta-html (genre [b] pour <b>) avec des attributs connus et plus faciles à valider.
HTH a++; JG
Bonour,
Pour différentes interfaces on a souvent besoin d'autoriser un peu de
HTML dans les entrées utilisateur mais strip_tags ne permet pas de
vérifier le contenu des tags autorisés (attributs et valeurs).
Malheureusement, oui.
Donc je recherche un script qui permet de parser une chaîne en
supprimant tous les tags sauf ceux qui sont autorisés,
Jusqu'ici, strip_tags suffit. La première partie du boulot est faite,
reste à aller vérifier les attributs.
mais dans ces
dernier qui limite également pour chacun les attributs autorisés et si
possible leur valeurs (ou type).
Là, il faut le faire.
Bref je suis à l'écoute des suggestions, c'est peut-être plus simple que
je ne l'imagine.
Des exemples d'attaques à contrer sont disponibles sur
http://ha.ckers.org/xss.html
Pas évident de trouver une méthode simple et idiot-proof pour
différencier un contenu d'attribut valide d'une injection. Moi je
voterais pour n'autoriser que les tags bruts sans attributs, ou je
gèrerais ça en tant que liste fermée d'attributs autorisés par tag
(aussi bien le nom de l'attribut que son contenu). Dans tous les cas, il
va falloir parser allègrement et ça va être lourd.
Je pense que des réponses plus éclairées seraient disponibles dans les
archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à
la solution d'une espèce de méta-html (genre [b] pour <b>) avec des
attributs connus et plus faciles à valider.
Pour différentes interfaces on a souvent besoin d'autoriser un peu de HTML dans les entrées utilisateur mais strip_tags ne permet pas de vérifier le contenu des tags autorisés (attributs et valeurs).
Malheureusement, oui.
Donc je recherche un script qui permet de parser une chaîne en supprimant tous les tags sauf ceux qui sont autorisés,
Jusqu'ici, strip_tags suffit. La première partie du boulot est faite, reste à aller vérifier les attributs.
mais dans ces dernier qui limite également pour chacun les attributs autorisés et si possible leur valeurs (ou type). Là, il faut le faire.
Bref je suis à l'écoute des suggestions, c'est peut-être plus simple que je ne l'imagine. Des exemples d'attaques à contrer sont disponibles sur
http://ha.ckers.org/xss.html
Pas évident de trouver une méthode simple et idiot-proof pour différencier un contenu d'attribut valide d'une injection. Moi je voterais pour n'autoriser que les tags bruts sans attributs, ou je gèrerais ça en tant que liste fermée d'attributs autorisés par tag (aussi bien le nom de l'attribut que son contenu). Dans tous les cas, il va falloir parser allègrement et ça va être lourd.
Je pense que des réponses plus éclairées seraient disponibles dans les archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à la solution d'une espèce de méta-html (genre [b] pour <b>) avec des attributs connus et plus faciles à valider.
HTH a++; JG
Sebastien
Bonour,
Des exemples d'attaques à contrer sont disponibles sur http://ha.ckers.org/xss.html
Merci pour le lien. Très intéressant, ça rappelle une fois de plus que peu de développeurs connaissent vraiment HTML et les règles issues de SGML qu'il observe.
Pas évident de trouver une méthode simple et idiot-proof pour différencier un contenu d'attribut valide d'une injection. Moi je voterais pour n'autoriser que les tags bruts sans attributs, ou je
Il faut bien autoriser "href" pour "a" (dans ce cas si on va jusqu'au bout, il faut au moins valider la structure de l'URL), je veux aussi autoriser "hreflang" et "title". De même pour "blocquote", ne pas autoriser "cite" est frustrant. Je veux aussi autoriser "lang" sur toutes les balises autorisées (dans ce cas pour aller jusqu'au bout il faudrait parser la valeur par rapport à une liste de langues : code à 2 ou 3 lettres, code composés langue-PAYS...).
gèrerais ça en tant que liste fermée d'attributs autorisés par tag (aussi bien le nom de l'attribut que son contenu). Dans tous les cas, il va falloir parser allègrement et ça va être lourd.
oui...
Pour l'instant je n'autorise rien. Je fais un strip_tag() sans exception, un htmlspecialchars() et un trim(). Je pense que c'est 100% sûr, mais je suis ouvert aux suggestions.
C'est tout de même loin d'être convivial.
Je pense que des réponses plus éclairées seraient disponibles dans les archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à la solution d'une espèce de méta-html (genre [b] pour <b>) avec des attributs connus et plus faciles à valider.
Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle est utilisée ailleurs, n'est pas aussi universelle que HTML.
De plus je pense utiliser des boutons qui incluront les balises dans le champ textarea, ce qui permet donc en fait à tous d'utiliser l'interface. Mais c'est là qu'on autorise l'erreur et qu'on ne peut plus faire confiance aux données entrées.
Je dois dire aussi que ma préoccupation première n'est pas la sécurité mais la validité (HTML) des données. Je pense que si on interdit le JavaScript et qu'on limite strictement le choix des attributs pour chaque élément et qu'on vérifie (cerise sur le gâteau) le codage des caractères (utf-8 pour moi), ça doit limiter les possibilités d'attaques ou de nuisances.
Mais c'est effectievement un vaste sujet (la sécurité), à explorer également.
Sébastien
Bonour,
Des exemples d'attaques à contrer sont disponibles sur
http://ha.ckers.org/xss.html
Merci pour le lien. Très intéressant, ça rappelle une fois de plus que
peu de développeurs connaissent vraiment HTML et les règles issues de
SGML qu'il observe.
Pas évident de trouver une méthode simple et idiot-proof pour
différencier un contenu d'attribut valide d'une injection. Moi je
voterais pour n'autoriser que les tags bruts sans attributs, ou je
Il faut bien autoriser "href" pour "a" (dans ce cas si on va jusqu'au
bout, il faut au moins valider la structure de l'URL), je veux aussi
autoriser "hreflang" et "title". De même pour "blocquote", ne pas
autoriser "cite" est frustrant.
Je veux aussi autoriser "lang" sur toutes les balises autorisées (dans
ce cas pour aller jusqu'au bout il faudrait parser la valeur par rapport
à une liste de langues : code à 2 ou 3 lettres, code composés
langue-PAYS...).
gèrerais ça en tant que liste fermée d'attributs autorisés par tag
(aussi bien le nom de l'attribut que son contenu). Dans tous les cas, il
va falloir parser allègrement et ça va être lourd.
oui...
Pour l'instant je n'autorise rien. Je fais un strip_tag() sans
exception, un htmlspecialchars() et un trim(). Je pense que c'est 100%
sûr, mais je suis ouvert aux suggestions.
C'est tout de même loin d'être convivial.
Je pense que des réponses plus éclairées seraient disponibles dans les
archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à
la solution d'une espèce de méta-html (genre [b] pour <b>) avec des
attributs connus et plus faciles à valider.
Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui
ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle
est utilisée ailleurs, n'est pas aussi universelle que HTML.
De plus je pense utiliser des boutons qui incluront les balises dans le
champ textarea, ce qui permet donc en fait à tous d'utiliser
l'interface. Mais c'est là qu'on autorise l'erreur et qu'on ne peut plus
faire confiance aux données entrées.
Je dois dire aussi que ma préoccupation première n'est pas la sécurité
mais la validité (HTML) des données. Je pense que si on interdit le
JavaScript et qu'on limite strictement le choix des attributs pour
chaque élément et qu'on vérifie (cerise sur le gâteau) le codage des
caractères (utf-8 pour moi), ça doit limiter les possibilités d'attaques
ou de nuisances.
Mais c'est effectievement un vaste sujet (la sécurité), à explorer
également.
Des exemples d'attaques à contrer sont disponibles sur http://ha.ckers.org/xss.html
Merci pour le lien. Très intéressant, ça rappelle une fois de plus que peu de développeurs connaissent vraiment HTML et les règles issues de SGML qu'il observe.
Pas évident de trouver une méthode simple et idiot-proof pour différencier un contenu d'attribut valide d'une injection. Moi je voterais pour n'autoriser que les tags bruts sans attributs, ou je
Il faut bien autoriser "href" pour "a" (dans ce cas si on va jusqu'au bout, il faut au moins valider la structure de l'URL), je veux aussi autoriser "hreflang" et "title". De même pour "blocquote", ne pas autoriser "cite" est frustrant. Je veux aussi autoriser "lang" sur toutes les balises autorisées (dans ce cas pour aller jusqu'au bout il faudrait parser la valeur par rapport à une liste de langues : code à 2 ou 3 lettres, code composés langue-PAYS...).
gèrerais ça en tant que liste fermée d'attributs autorisés par tag (aussi bien le nom de l'attribut que son contenu). Dans tous les cas, il va falloir parser allègrement et ça va être lourd.
oui...
Pour l'instant je n'autorise rien. Je fais un strip_tag() sans exception, un htmlspecialchars() et un trim(). Je pense que c'est 100% sûr, mais je suis ouvert aux suggestions.
C'est tout de même loin d'être convivial.
Je pense que des réponses plus éclairées seraient disponibles dans les archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à la solution d'une espèce de méta-html (genre [b] pour <b>) avec des attributs connus et plus faciles à valider.
Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle est utilisée ailleurs, n'est pas aussi universelle que HTML.
De plus je pense utiliser des boutons qui incluront les balises dans le champ textarea, ce qui permet donc en fait à tous d'utiliser l'interface. Mais c'est là qu'on autorise l'erreur et qu'on ne peut plus faire confiance aux données entrées.
Je dois dire aussi que ma préoccupation première n'est pas la sécurité mais la validité (HTML) des données. Je pense que si on interdit le JavaScript et qu'on limite strictement le choix des attributs pour chaque élément et qu'on vérifie (cerise sur le gâteau) le codage des caractères (utf-8 pour moi), ça doit limiter les possibilités d'attaques ou de nuisances.
Mais c'est effectievement un vaste sujet (la sécurité), à explorer également.
Sébastien
Laurent Seguin
Le Tue, 08 Nov 2005 22:33:21 +0000, Sebastien :
Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle est utilisée ailleurs, n'est pas aussi universelle que HTML.
Bof. Maintenant je met tous mes formulaires de back-office en wiki ; En y associant un bon JS avec des boutons "a la word" (chourré dans le BO de Dotclear) les utilisateurs (et j'ai de sacrés neu²) s'en sortent bien.
En classe PHP de transformation wiki sympa tu as : WikiRenderer => http://ljouanneau.com/softs/wikirenderer/ Wiki2Xhtml => http://www.neokraft.net/sottises/wiki2xhtml/
++
Le Tue, 08 Nov 2005 22:33:21 +0000, Sebastien :
Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui
ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle
est utilisée ailleurs, n'est pas aussi universelle que HTML.
Bof. Maintenant je met tous mes formulaires de back-office en wiki ; En
y associant un bon JS avec des boutons "a la word" (chourré dans le BO
de Dotclear) les utilisateurs (et j'ai de sacrés neu²) s'en sortent
bien.
En classe PHP de transformation wiki sympa tu as :
WikiRenderer => http://ljouanneau.com/softs/wikirenderer/
Wiki2Xhtml => http://www.neokraft.net/sottises/wiki2xhtml/
Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle est utilisée ailleurs, n'est pas aussi universelle que HTML.
Bof. Maintenant je met tous mes formulaires de back-office en wiki ; En y associant un bon JS avec des boutons "a la word" (chourré dans le BO de Dotclear) les utilisateurs (et j'ai de sacrés neu²) s'en sortent bien.
En classe PHP de transformation wiki sympa tu as : WikiRenderer => http://ljouanneau.com/softs/wikirenderer/ Wiki2Xhtml => http://www.neokraft.net/sottises/wiki2xhtml/
++
John GALLET
Re,
Merci pour le lien. Très intéressant, Je trouve aussi. Déjà référencé dans mon petit doc sécurité. J'en ai
fait passer un certain nombre à strip_tags, pour rigoler, aucune des celles que j'ai essayées ne passe.
Il faut bien autoriser "href" pour "a" (dans ce cas si on va jusqu'au bout, il faut au moins valider la structure de l'URL), En effet, certains tags ont des attributs obligatoires, je ne pensais
qu'à des tags de mise en forme en fait.
Pour l'instant je n'autorise rien. Je fais un strip_tag() sans exception, un htmlspecialchars() et un trim(). Je pense que c'est 100% sûr, mais je suis ouvert aux suggestions.
En terme d'anti xss, l'un ou l'autre (strip_tag/htmlspecialchars) doit suffire.
C'est tout de même loin d'être convivial. Notion très personnelle. Je trouve Usenet très convivial, même lu sous
pine ou slrn. Je trouve vi relativement convivial (et oui, quand on a commencé à éditer des fichiers sous edlin, vi *est* convivial, parce qu'éditer une ligne à la fois, c'est chiant).
Je pense que des réponses plus éclairées seraient disponibles dans les archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à la solution d'une espèce de méta-html (genre [b] pour <b>) avec des attributs connus et plus faciles à valider. Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui
ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle est utilisée ailleurs, n'est pas aussi universelle que HTML.
Tu dois pouvoir leur faciliter la tâche en rendant ceci transparent en JS côté client pour qu'ils n'aient pas à gérer la saisie.
J'ai vu passer aussi une suggestion récemment sur les listes security-focus, qui consiste à utiliser du XHTML et donc pouvoir valider de manière "transparente" avec une DTD. Ce sera aussi lourd en termes d'exécution, mais ce sera sacrément plus simple à coder, surtout vu ta remarque sur le fait que c'est la validité qui est à ton sens primordiale.
Je dois dire aussi que ma préoccupation première n'est pas la sécurité mais la validité (HTML) des données. Je pense que si on interdit le JavaScript et qu'on limite strictement le choix des attributs pour chaque élément et qu'on vérifie (cerise sur le gâteau) le codage des caractères (utf-8 pour moi), ça doit limiter les possibilités d'attaques ou de nuisances.
Oui, la partie chiante à coder étant la liste à trois étages des valeurs autorisées. Ensuite, en profiter pour valider le codage des caractères, on est plus à ça près.
Mais c'est effectievement un vaste sujet (la sécurité), à explorer également.
Pour moi, c'est plus important que la "convivialité". Un site convivial complètement 0wn3d, c'est pas convivial longtemps (enfin, ça dépend pour qui :-))...) A mon sens, la sécurité est un prérequis.
a++; JG
Re,
Merci pour le lien. Très intéressant,
Je trouve aussi. Déjà référencé dans mon petit doc sécurité. J'en ai
fait passer un certain nombre à strip_tags, pour rigoler, aucune des
celles que j'ai essayées ne passe.
Il faut bien autoriser "href" pour "a" (dans ce cas si on va jusqu'au
bout, il faut au moins valider la structure de l'URL),
En effet, certains tags ont des attributs obligatoires, je ne pensais
qu'à des tags de mise en forme en fait.
Pour l'instant je n'autorise rien. Je fais un strip_tag() sans
exception, un htmlspecialchars() et un trim(). Je pense que c'est 100%
sûr, mais je suis ouvert aux suggestions.
En terme d'anti xss, l'un ou l'autre (strip_tag/htmlspecialchars) doit
suffire.
C'est tout de même loin d'être convivial.
Notion très personnelle. Je trouve Usenet très convivial, même lu sous
pine ou slrn. Je trouve vi relativement convivial (et oui, quand on a
commencé à éditer des fichiers sous edlin, vi *est* convivial, parce
qu'éditer une ligne à la fois, c'est chiant).
Je pense que des réponses plus éclairées seraient disponibles dans les
archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à
la solution d'une espèce de méta-html (genre [b] pour <b>) avec des
attributs connus et plus faciles à valider.
Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui
ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle
est utilisée ailleurs, n'est pas aussi universelle que HTML.
Tu dois pouvoir leur faciliter la tâche en rendant ceci transparent en
JS côté client pour qu'ils n'aient pas à gérer la saisie.
J'ai vu passer aussi une suggestion récemment sur les listes
security-focus, qui consiste à utiliser du XHTML et donc pouvoir valider
de manière "transparente" avec une DTD. Ce sera aussi lourd en termes
d'exécution, mais ce sera sacrément plus simple à coder, surtout vu ta
remarque sur le fait que c'est la validité qui est à ton sens primordiale.
Je dois dire aussi que ma préoccupation première n'est pas la sécurité
mais la validité (HTML) des données. Je pense que si on interdit le
JavaScript et qu'on limite strictement le choix des attributs pour
chaque élément et qu'on vérifie (cerise sur le gâteau) le codage des
caractères (utf-8 pour moi), ça doit limiter les possibilités d'attaques
ou de nuisances.
Oui, la partie chiante à coder étant la liste à trois étages des valeurs
autorisées. Ensuite, en profiter pour valider le codage des caractères,
on est plus à ça près.
Mais c'est effectievement un vaste sujet (la sécurité), à explorer
également.
Pour moi, c'est plus important que la "convivialité". Un site convivial
complètement 0wn3d, c'est pas convivial longtemps (enfin, ça dépend pour
qui :-))...) A mon sens, la sécurité est un prérequis.
Merci pour le lien. Très intéressant, Je trouve aussi. Déjà référencé dans mon petit doc sécurité. J'en ai
fait passer un certain nombre à strip_tags, pour rigoler, aucune des celles que j'ai essayées ne passe.
Il faut bien autoriser "href" pour "a" (dans ce cas si on va jusqu'au bout, il faut au moins valider la structure de l'URL), En effet, certains tags ont des attributs obligatoires, je ne pensais
qu'à des tags de mise en forme en fait.
Pour l'instant je n'autorise rien. Je fais un strip_tag() sans exception, un htmlspecialchars() et un trim(). Je pense que c'est 100% sûr, mais je suis ouvert aux suggestions.
En terme d'anti xss, l'un ou l'autre (strip_tag/htmlspecialchars) doit suffire.
C'est tout de même loin d'être convivial. Notion très personnelle. Je trouve Usenet très convivial, même lu sous
pine ou slrn. Je trouve vi relativement convivial (et oui, quand on a commencé à éditer des fichiers sous edlin, vi *est* convivial, parce qu'éditer une ligne à la fois, c'est chiant).
Je pense que des réponses plus éclairées seraient disponibles dans les archives et/ou en thread sur fr.comp.securite (modéré). Penser aussi à la solution d'une espèce de méta-html (genre [b] pour <b>) avec des attributs connus et plus faciles à valider. Je préfère autoriser le HTML car je ne veux pas imposer à des gens qui
ont fait l'effort d'apprendre HTML une autre syntaxe qui, même si elle est utilisée ailleurs, n'est pas aussi universelle que HTML.
Tu dois pouvoir leur faciliter la tâche en rendant ceci transparent en JS côté client pour qu'ils n'aient pas à gérer la saisie.
J'ai vu passer aussi une suggestion récemment sur les listes security-focus, qui consiste à utiliser du XHTML et donc pouvoir valider de manière "transparente" avec une DTD. Ce sera aussi lourd en termes d'exécution, mais ce sera sacrément plus simple à coder, surtout vu ta remarque sur le fait que c'est la validité qui est à ton sens primordiale.
Je dois dire aussi que ma préoccupation première n'est pas la sécurité mais la validité (HTML) des données. Je pense que si on interdit le JavaScript et qu'on limite strictement le choix des attributs pour chaque élément et qu'on vérifie (cerise sur le gâteau) le codage des caractères (utf-8 pour moi), ça doit limiter les possibilités d'attaques ou de nuisances.
Oui, la partie chiante à coder étant la liste à trois étages des valeurs autorisées. Ensuite, en profiter pour valider le codage des caractères, on est plus à ça près.
Mais c'est effectievement un vaste sujet (la sécurité), à explorer également.
Pour moi, c'est plus important que la "convivialité". Un site convivial complètement 0wn3d, c'est pas convivial longtemps (enfin, ça dépend pour qui :-))...) A mon sens, la sécurité est un prérequis.
