Anomalie #3371

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

Ajouté par Fabien Abbadie il y a presque 3 ans. Mis à jour il y a 2 mois.

Statut:FerméDébut:04/01/2015
Priorité:ImmédiatEchéance:
Assigné à:-% réalisé:

0%

Catégorie:sécurité
Version cible:3.1
Resolution:fixed Navigateur:

Description

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.

piratage_art85_flou.jpg (73,675 ko) Fabien Abbadie, 04/01/2015 19:31

piratage_identite_site_flou.jpg (35,64 ko) Fabien Abbadie, 04/01/2015 19:31

Révisions associées

Révision 22428
Ajouté par cedric@yterium.com il y a environ 2 ans

Fix #3371 : dans la fonction typo, si un flag espace_prive=1 est present dans le env, on echappe tout html suspect, ie qui ne passe pas a travers safehtml sans censure. Pour limiter l'impact perfo on conditionne l'echappement a la presence des caracteres < et = dans le texte, c'est a dire une balise avec un attribut, ce qui ne traitera donc quasiment aucun contenu par defaut, sauf quelques rares <span lang='en'> ou autre curiosite de ce type

Révision 22450
Ajouté par cedric@yterium.com il y a environ 2 ans

Report de r22428 : Fix #3371 : dans la fonction typo, si un flag espace_prive=1 est present dans le env, on echappe tout html suspect, ie qui ne passe pas a travers safehtml sans censure. Pour limiter l'impact perfo on conditionne l'echappement a la presence des caracteres < et = dans le texte, c'est a dire une balise avec un attribut, ce qui ne traitera donc quasiment aucun contenu par defaut, sauf quelques rares <span lang='en'> ou autre curiosite de ce type

Historique

#1 Mis à jour par Fil _ il y a presque 3 ans

  • Statut changé de Nouveau à 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.

#2 Mis à jour par Fabien Abbadie il y a presque 3 ans

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

#3 Mis à jour par Fil _ il y a presque 3 ans

  • Sujet changé de faille sécurité ? balise meta dans un champ d'article à faille sécurité ? balise meta+refresh dans un champ d'article
  • Catégorie mis à sécurité
  • Statut changé de Fermé à En cours
  • Version cible mis à 3.1

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 ?

#4 Mis à jour par cam.lafit - il y a presque 3 ans

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.

#5 Mis à jour par RastaPopoulos ♥ il y a presque 3 ans

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.

#6 Mis à jour par goldstein goldstein il y a presque 3 ans

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.

#7 Mis à jour par Fabien Abbadie il y a presque 3 ans

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.

#8 Mis à jour par b b il y a plus de 2 ans

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

#9 Mis à jour par b b il y a plus de 2 ans

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.

#10 Mis à jour par cedric - il y a plus de 2 ans

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.

#11 Mis à jour par cedric - il y a plus de 2 ans

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

#12 Mis à jour par b b il y a plus de 2 ans

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.

#13 Mis à jour par cedric - il y a environ 2 ans

  • Statut changé de En cours à Fermé
  • Resolution mis à fixed

#14 Mis à jour par b b il y a environ 2 ans

Super, merci cedric :)

#15 Mis à jour par cedric - il y a 2 mois

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

#16 Mis à jour par b b il y a 2 mois

Todobien :)

Formats disponibles : Atom PDF

Ajouter une image à partir du presse-papier (Taille maximale: 1,25 Mo)