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

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.

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é

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

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

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.

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.

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.

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

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.

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.

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

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.

Statut changé à Fermé

Super, merci cedric :)

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

Todobien :)