Sécuriser l'edition d'un auteur #5256

Merged
marcimat merged 4 commits from issue_4833_editer_auteur into master 4 weeks ago
cerdic commented 1 month ago
Owner
  • on envoie un Header Content-Security-Policy: frame-ancestors 'none' sur les pages auteur et auteur_edit pour eviter toute manipulation via une iframe
  • (et pour ce faire un fix un bug sur #HTTP_HEADER)
  • on empeche la validation de #FORMULAIRE_EDITER_AUTEUR via une XMLHttpRequest dès qu'il y a changement de email ou mot de passe ou elevation du statut
  • (et pour ce faire un fix sur refuser_traiter_formulaire_ajax() qui ne marchait pas si on avait un element avec un name ou id submit dans un form, ce qui était le cas de ce formulaire)

Le tout est indirectement lié à spip-team/securite#4832 et spip-team/securite#4833 même si pas explicitement cité par la proof of concept

(XSS qui permet de manipuler des forms en XMLHttpRequest et du coup d'escalader ses droits ou d'usurper le compte d'un admin/webmestre)

- on envoie un Header `Content-Security-Policy: frame-ancestors 'none'` sur les pages auteur et auteur_edit pour eviter toute manipulation via une iframe - (et pour ce faire un fix un bug sur `#HTTP_HEADER`) - on empeche la validation de `#FORMULAIRE_EDITER_AUTEUR` via une XMLHttpRequest dès qu'il y a changement de email ou mot de passe ou elevation du statut - (et pour ce faire un fix sur `refuser_traiter_formulaire_ajax()` qui ne marchait pas si on avait un element avec un name ou id submit dans un form, ce qui était le cas de ce formulaire) Le tout est indirectement lié à https://git.spip.net/spip-team/securite/issues/4832 et https://git.spip.net/spip-team/securite/issues/4833 même si pas explicitement cité par la proof of concept (XSS qui permet de manipuler des forms en XMLHttpRequest et du coup d'escalader ses droits ou d'usurper le compte d'un admin/webmestre)
cerdic force-pushed issue_4833_editer_auteur from 02ff89c5c4 to 0ded06666c 1 month ago
b_b approved these changes 1 month ago
cerdic added 7 commits 1 month ago
Poster
Owner

J'ai rebasé la PR, et modifié l'envoi des CSP pour qu'il soit sur tout ecrire/

Le risque c'est pour des utilisateurs qui auraient tout leur site en iframe (pour l'afficher sous un autre nom de domaine, parce qu'ils peuvent pas faire autrement avec leur hébergement, j'en ai vu...), qui ne pourront plus accéder à ecrire/ depuis l'iframe. Ils devront utiliser directement le nom de domaine auquel répond le site et qu'ils cachaient via l'iframe

J'ai rebasé la PR, et modifié l'envoi des CSP pour qu'il soit sur tout ecrire/ Le risque c'est pour des utilisateurs qui auraient tout leur site en iframe (pour l'afficher sous un autre nom de domaine, parce qu'ils peuvent pas faire autrement avec leur hébergement, j'en ai vu...), qui ne pourront plus accéder à ecrire/ depuis l'iframe. Ils devront utiliser directement le nom de domaine auquel répond le site et qu'ils cachaient via l'iframe
b_b commented 1 month ago
Owner

Le risque c'est pour des utilisateurs qui auraient tout leur site en iframe

Ça me semble suffisament à la marge pour ne pas s'en occuper :p

> Le risque c'est pour des utilisateurs qui auraient tout leur site en iframe Ça me semble suffisament à la marge pour ne pas s'en occuper :p
marcimat approved these changes 1 month ago
marcimat added 4 commits 4 weeks ago
Owner

L’effet skew-x-shakeng est plutôt surprenant, on se demande qu’est-ce qui se passe… mais bon, ça doit pas être dramatique :)

L’effet skew-x-shakeng est plutôt surprenant, on se demande qu’est-ce qui se passe… mais bon, ça doit pas être dramatique :)
marcimat merged commit c3d345e5a6 into master 4 weeks ago
marcimat deleted branch issue_4833_editer_auteur 4 weeks ago
Owner

J’ai reporté en 4.1 et 4.0.

Pour SPIP 3.2 je ne sais pas ?
(y a des conflits à droite à gauche)

J’ai reporté en 4.1 et 4.0. Pour SPIP 3.2 je ne sais pas ? (y a des conflits à droite à gauche)
b_b commented 4 weeks ago
Owner

Ouep ça risque d'être chaud pour le report en 3.2, en plus des confilts il faudrait veiller à ne pas introduire d'écritures PHP incompatibles avec la version 5.6...

Ouep ça risque d'être chaud pour le report en 3.2, en plus des confilts il faudrait veiller à ne pas introduire d'écritures PHP incompatibles avec la version 5.6...
Owner

Pour les écritures, j’ai corrigé déjà pour les autres reports ensuite avec php-compatibility (avec PHP 5.4 d’ailleurs, pas 5.6 pour SPIP 3.2)
Je ne pense pas que ça soit la partie la plus compliquée.

Y a peut être un report partiel à faire en 3.2, mais pas de l’ensemble ?

À voir avec @cerdic pitêtre ce qu’il en pense ?

Pour les écritures, j’ai corrigé déjà pour les autres reports ensuite avec php-compatibility (avec PHP 5.4 d’ailleurs, pas 5.6 pour SPIP 3.2) Je ne pense pas que ça soit la partie la plus compliquée. Y a peut être un report partiel à faire en 3.2, mais pas de l’ensemble ? À voir avec @cerdic pitêtre ce qu’il en pense ?
Poster
Owner

on peut aussi décider de vivre sans en 3.2. En soi on ne corrige pas une faille, mais un risque d'exploitation via une faille xss.

on peut aussi décider de vivre sans en 3.2. En soi on ne corrige pas une faille, mais un risque d'exploitation via une faille xss.
b_b commented 4 weeks ago
Owner

Comme je le disais sur IRC, chaque action lancée depuis le page des plugins (en cliquant sur le bouton Actions d'un plugin) déclenche l'effet skew en question. Je ne sais pas si c'est voulu, mais c'est étrange visuellement.

Comme je le disais sur IRC, chaque action lancée depuis le page des plugins (en cliquant sur le bouton Actions d'un plugin) déclenche l'effet skew en question. Je ne sais pas si c'est voulu, mais c'est étrange visuellement.

Reviewers

b_b approved these changes 1 month ago
marcimat approved these changes 1 month ago
The pull request has been merged as c3d345e5a6.
Sign in to join this conversation.
Loading…
There is no content yet.