faille sécurité ? balise meta+refresh dans un champ d'article #3371

Closed
opened 8 years ago by miros · 16 comments
miros commented 8 years ago

Suite à un piratage sur une version 3.0.5, je me suis aperçu que Spip interprétait les balises html meta qu'on mettait dans divers champs avec une redirection :
J'ai testé sur une 3.0.17 et ça le faisait aussi.
On peut notamment mettre ça en titre d'articles et dès que c'est listé dans un catégorie ou autre, ça redirige la page, y compris dans la zone privée.

On peut neutraliser l'effet en bloquant la redirection avec le navigateur (option de Firefox) pour corriger mais tout ça me semble extrêmement dangereux.

Suite à un piratage sur une version 3.0.5, je me suis aperçu que Spip interprétait les balises html meta qu'on mettait dans divers champs avec une redirection : <meta http-equiv="refresh" content="0 ; URL =’ une page pirate’ "> J'ai testé sur une 3.0.17 et ça le faisait aussi. On peut notamment mettre ça en titre d'articles et dès que c'est listé dans un catégorie ou autre, ça redirige la page, y compris dans la zone privée. On peut neutraliser l'effet en bloquant la redirection avec le navigateur (option de Firefox) pour corriger mais tout ça me semble extrêmement dangereux.
Fil commented 8 years ago
Owner

Pour moi le problème de sécu vient du piratage qui a eu lieu, pas de ce que le pirate a fait une fois dans la place... Essentiellement il est passé admin, et les admins gardent le droit de faire des choses intéressantes dans leur site.
Statut changé à Fermé

Pour moi le problème de sécu vient du piratage qui a eu lieu, pas de ce que le pirate a fait une fois dans la place... Essentiellement il est passé admin, et les admins gardent le droit de faire des choses intéressantes dans leur site. **Statut changé à Fermé**
Poster

Fil Up a écrit :

Pour moi le problème de sécu vient du piratage qui a eu lieu, pas de ce que le pirate a fait une fois dans la place... Essentiellement il est passé admin, et les admins gardent le droit de faire des choses intéressantes dans leur site.

Oui mais non : j'ai testé sur une 3.0.17 à jour, pas piraté, et a priori, n'importe quel rédacteur peut faire ça.
J'ai même testé sur forum.spip.net et ça a l'air de le faire aussi fait : mettez en titre, et voyons si les utilisateurs sont contents quand ils sont renvoyés vers une page piégé à chaque fois que l'article est listé.

Si vous pouvez, essayez de voir cet article, proof of concept : http://forum.spip.net/ecrire/?exec=article&id_article=3140

Fil Up a écrit : > Pour moi le problème de sécu vient du piratage qui a eu lieu, pas de ce que le pirate a fait une fois dans la place... Essentiellement il est passé admin, et les admins gardent le droit de faire des choses intéressantes dans leur site. Oui mais non : j'ai testé sur une 3.0.17 à jour, pas piraté, et a priori, n'importe quel rédacteur peut faire ça. J'ai même testé sur forum.spip.net et ça a l'air de le faire aussi fait : mettez <meta http-equiv="refresh" content="0 ; URL =’ une page pirate’ "> en titre, et voyons si les utilisateurs sont contents quand ils sont renvoyés vers une page piégé à chaque fois que l'article est listé. Si vous pouvez, essayez de voir cet article, proof of concept : http://forum.spip.net/ecrire/?exec=article&id_article=3140
Fil commented 8 years ago
Owner

ah oui de ce point de vue ; il faudrait le bloquer dans l'espace privé pour les articles non validés, comme les attributs js des tags img ?
Version cible mise à 3.1
Statut changé à En cours

ah oui de ce point de vue ; il faudrait le bloquer dans l'espace privé pour les articles non validés, comme les attributs js des tags img ? **Version cible mise à 3.1** **Statut changé à En cours**
Owner

Bonjour

En fait il y a un principe de base qui fait que si un rédacteur a le
droit d'écrire alors il a le droit d'écrire ce qu'il veut. Ainsi il
n'y pas de contrôle pour le bien du rédacteur.

En l'état ce serait plus le rôle d'un plugin de faire ces contrôles,
par défaut SPIP fait confiance.

Qu'une personne non autorisée ait pu rédiger du texte (quel qu’il soit
en pratique) est par contre un vrai problème.

Bonjour En fait il y a un principe de base qui fait que si un rédacteur a le droit d'écrire alors il a le droit d'écrire ce qu'il veut. Ainsi il n'y pas de contrôle pour le *bien* du rédacteur. En l'état ce serait plus le rôle d'un plugin de faire ces contrôles, par défaut SPIP fait confiance. Qu'une personne non autorisée ait pu rédiger du texte (quel qu’il soit en pratique) est par contre un vrai problème.

Sauf que le fait d'autoriser l'inscription ouverte est une fonctionnalité de la distribution par défaut, ce n'est pas un plugin. Donc la protection dans le cas où l'inscription est ouverte devrait aussi se trouver par défaut, pas en plugin. Ça doit aller ensemble.

Sauf que le fait d'autoriser l'inscription ouverte est une fonctionnalité de la distribution par défaut, ce n'est pas un plugin. Donc la protection dans le cas où l'inscription est ouverte devrait aussi se trouver par défaut, pas en plugin. Ça doit aller ensemble.
Owner

Ciao

Sauf que le fait d'autoriser l'inscription ouverte est une fonctionnalité de la distribution par défaut, ce n'est pas un plugin.

Par défaut SPIP fait confiance. Donc l'un et l'autre semblent logiques ainsi. Après est ce qu'on est d'accord ou pas, c'est un débat complémentaire.

Ciao > Sauf que le fait d'autoriser l'inscription ouverte est une fonctionnalité de la distribution par défaut, ce n'est pas un plugin. Par défaut SPIP fait confiance. Donc l'un et l'autre semblent logiques ainsi. Après est ce qu'on est d'accord ou pas, c'est un débat complémentaire.
Poster

RastaPopoulos ♥ a écrit :

Sauf que le fait d'autoriser l'inscription ouverte est une fonctionnalité de la distribution par défaut, ce n'est pas un plugin. Donc la protection dans le cas où l'inscription est ouverte devrait aussi se trouver par défaut, pas en plugin. Ça doit aller ensemble.

D'autant plus qu'on se demande bien qui ferait cet usage si ce n'est dans une intention malveillante.

RastaPopoulos ♥ a écrit : > Sauf que le fait d'autoriser l'inscription ouverte est une fonctionnalité de la distribution par défaut, ce n'est pas un plugin. Donc la protection dans le cas où l'inscription est ouverte devrait aussi se trouver par défaut, pas en plugin. Ça doit aller ensemble. D'autant plus qu'on se demande bien qui ferait cet usage si ce n'est dans une intention malveillante.
b_b commented 8 years ago
Owner

HS : pour info, wp "fait aussi confiance", le bug est aussi présent chez eux sur une 4.2.1.

HS : pour info, wp "fait aussi confiance", le bug est aussi présent chez eux sur une 4.2.1.
b_b commented 8 years ago
Owner

J'ai souvenir qu'on a le même problème avec l'exécution de tags js dans le titre des articles. En suivant le conseil de Fil, on pourrait bloquer l'usage des tags meta et script dans les titres des éléments pour les rédacteurs ?

Maj de la liste des tags à exclure : meta, script, iframe.

J'ai souvenir qu'on a le même problème avec l'exécution de tags js dans le titre des articles. En suivant le conseil de Fil, on pourrait bloquer l'usage des tags meta et script dans les titres des éléments pour les rédacteurs ? Maj de la liste des tags à exclure : meta, script, iframe.
Owner

Est-ce qu'une solution intermédiaire plus acceptable serait de n'accepter que les tags sans attribut ou une whitelist d'attributs (je pense notamment à lang pour permettre de mettre un <span lang='en'>) dans les titre pour les securiser ? Cela eviterait les cas des javascript sur les hover, onclick, onload ou autre.
Cette sanitization active par défaut serait désactivable pour compatibilité avec les anciens sites qui feraient usage de html plus compliqué dans les titre.

Est-ce qu'une solution intermédiaire plus acceptable serait de n'accepter que les tags sans attribut ou une whitelist d'attributs (je pense notamment à lang pour permettre de mettre un `<span lang='en'>`) dans les titre pour les securiser ? Cela eviterait les cas des javascript sur les hover, onclick, onload ou autre. Cette sanitization active par défaut serait désactivable pour compatibilité avec les anciens sites qui feraient usage de html plus compliqué dans les titre.
Owner

Puisque la 3.1 affiche surtitre et sous titre dans les listes, il faut maintenant sanitizer ces 2 champs également

Puisque la 3.1 affiche surtitre et sous titre dans les listes, il faut maintenant sanitizer ces 2 champs également
b_b commented 8 years ago
Owner

Bonne idée pour le blocage des attributs non référencés dans une liste blanche. Mais je pense qu'on peut aussi bloquer les balises meta, script et iframe qui amha n'ont rien à faire dans un des champs de titrage.

Bonne idée pour le blocage des attributs non référencés dans une liste blanche. Mais je pense qu'on peut aussi bloquer les balises meta, script et iframe qui amha n'ont rien à faire dans un des champs de titrage.
Owner

Statut changé à Fermé

**Statut changé à Fermé**
b_b commented 7 years ago
Owner

Super, merci cedric :)

Super, merci cedric :)
Owner

r23701 https://zone.spip.org/trac/spip-zone/changeset/106234 et r23703 complètent la sécurisation sur les champs texte des objets éditoriaux (tout ce qui passe dans propre()) et sur le champ PGP de l'auteur

r23701 https://zone.spip.org/trac/spip-zone/changeset/106234 et r23703 complètent la sécurisation sur les champs texte des objets éditoriaux (tout ce qui passe dans propre()) et sur le champ PGP de l'auteur
b_b commented 5 years ago
Owner

Todobien :)

Todobien :)
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.