Project

General

Profile

Anomalie #3371

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

Added by Fabien Abbadie over 6 years ago. Updated over 3 years ago.

Status:
Fermé
Priority:
Immédiat
Assignee:
-
Category:
sécurité
Target version:
Start date:
01/04/2015
Due date:
% Done:

0%

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 View (73.7 KB) Fabien Abbadie, 01/04/2015 07:31 PM

piratage_identite_site_flou.jpg View (35.6 KB) Fabien Abbadie, 01/04/2015 07:31 PM

Associated revisions

Revision 22428 (diff)
Added by cedric@yterium.com over 5 years ago

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

Revision 22450 (diff)
Added by cedric@yterium.com over 5 years ago

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

History

#1 Updated by Fil _ over 6 years ago

  • Status changed from Nouveau to 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 Updated by Fabien Abbadie over 6 years ago

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 Updated by Fil _ over 6 years ago

  • Subject changed from faille sécurité ? balise meta dans un champ d'article to faille sécurité ? balise meta+refresh dans un champ d'article
  • Category set to sécurité
  • Status changed from Fermé to En cours
  • Target version set to 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 Updated by cam.lafit - over 6 years ago

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 Updated by RastaPopoulos ♥ over 6 years ago

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 Updated by goldstein goldstein over 6 years ago

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 Updated by Fabien Abbadie over 6 years ago

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 Updated by b b about 6 years ago

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

#9 Updated by b b about 6 years ago

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 Updated by cedric - almost 6 years ago

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 Updated by cedric - almost 6 years ago

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

#12 Updated by b b almost 6 years ago

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 Updated by cedric - over 5 years ago

  • Status changed from En cours to Fermé
  • Resolution set to fixed

#14 Updated by b b over 5 years ago

Super, merci cedric :)

#15 Updated by cedric - over 3 years ago

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 Updated by b b over 3 years ago

Todobien :)

Also available in: Atom PDF