Nettoyer l’écran de sécurité #5055

Open
opened 10 months ago by marcimat · 10 comments
Owner

L’écran de sécurité fournit avec SPIP devrait toujours être à jour de sa version de SPIP, et donc limiter son action au strict nécessaire : c’est à dire ne pas avoir du code de correction de failles de SPIP 1.8, 1.9, etc…

Ça éviterait aussi au passage quelques erreurs d’analyse statique sur des fonctions qui n’existent plus du tout dans PHP…

À conserver

  • déclaration des constantes _ECRAN_SECURITE, _ECRAN_SECURITE_LOAD, _IS_BOT, _IS_BOT_FRIEND
  • $ecran_securite_raison = "robot agenda/double pagination";
  • Bloque les bots quand le load déborde

À questionner : retirer ?

  • les intval préventifs sur id_* (c’est parfois gênant)

À questionner : conserver ?

  • le $ecran_securite_raison = "exec";
  • Échappement xss referer
  • Echappement HTTP_X_FORWARDED_HOST
  • $ecran_securite_raison = "malformed connect argument";

À retirer

  • probablement tout le reste :)

Ça voudrait dire que cet écran serait à jour pour la version fournie par SPIP.
Mais donc, il faudrait actualiser aussi https://git.spip.net/spip-contrib-outils/securite

Il n’est peut être pas nécessaire de conserver du code des SPIP 1.8, 1.9 dedans, des SPIPs dont on n’assure plus du tout la maintenance. Logiquement (je suppose) ce dépot devrait être à jour «des versions maintenues» probablement, soit pour SPIP 3.2.0+ disons à ce jour.

La question se pose de quel versionnage donner à _ECRAN_SECURITE du spip/spip et de celui de spip-contrib-outils/securite.

Je passe les détails sur le résonnement (c’était trop de blabla), mais au final je propose + (méta-données de construction dans semver) une version propre à spip-contrib-outils/securite, tel que :

  • 2.0.0 dans spip/spip

Et pour spip-contrib-outils/securite

  • 2.0.0+1.4.5 (la version 2 de spip/spip + la version 1.4.5 du plugin en gros)
  • ou 2.0.0+1.4.5-spip-3.2 (ou en disant en plus que c’est pour spip-3.2 minimum)

À discuter… D’autant qu’il serait intéressant de le faire charger par Composer également.

L’écran de sécurité fournit avec SPIP devrait toujours être à jour de sa version de SPIP, et donc limiter son action au strict nécessaire : c’est à dire ne pas avoir du code de correction de failles de SPIP 1.8, 1.9, etc… Ça éviterait aussi au passage quelques erreurs d’analyse statique sur des fonctions qui n’existent plus du tout dans PHP… **À conserver** - déclaration des constantes `_ECRAN_SECURITE`, `_ECRAN_SECURITE_LOAD`, `_IS_BOT`, `_IS_BOT_FRIEND` - `$ecran_securite_raison = "robot agenda/double pagination";` - `Bloque les bots quand le load déborde` **À questionner : retirer ?** - les intval préventifs sur `id_*` (c’est parfois gênant) **À questionner : conserver ?** - le `$ecran_securite_raison = "exec";` - `Échappement xss referer` - `Echappement HTTP_X_FORWARDED_HOST` - `$ecran_securite_raison = "malformed connect argument";` **À retirer** - probablement tout le reste :) ---- Ça voudrait dire que cet écran serait à jour pour la version fournie par SPIP. Mais donc, il faudrait actualiser aussi https://git.spip.net/spip-contrib-outils/securite Il n’est peut être pas nécessaire de conserver du code des SPIP 1.8, 1.9 dedans, des SPIPs dont on n’assure plus du tout la maintenance. Logiquement (je suppose) ce dépot devrait être à jour «des versions maintenues» probablement, soit pour SPIP 3.2.0+ disons à ce jour. La question se pose de quel versionnage donner à `_ECRAN_SECURITE` du spip/spip et de celui de spip-contrib-outils/securite. Je passe les détails sur le résonnement (c’était trop de blabla), mais au final je propose `+` (méta-données de construction dans semver) une version propre à spip-contrib-outils/securite, tel que : - `2.0.0` dans spip/spip Et pour `spip-contrib-outils/securite` - `2.0.0+1.4.5` (la version 2 de spip/spip + la version 1.4.5 du plugin en gros) - ou `2.0.0+1.4.5-spip-3.2` (ou en disant en plus que c’est pour spip-3.2 minimum) À discuter… D’autant qu’il serait intéressant de le faire charger par Composer également.
marcimat added this to the 4.2 milestone 10 months ago
marcimat added the
sécurité
amélioration
labels 10 months ago
Owner

L'intention initiale était d'avoir quelque chose de simple et compréhensible et facile à mettre à jour. D'où un seul et unique écran pour toutes les versions de SPIP.

Je crains que versionner trop en détail rende toute les mises à jour cela illisibles, à tout le moins sans un mécanisme de mise à jour automatique du dit écran (ce qui avait été abordé puis mis en pause et jamais relancé).

On pourrait peut-être faire un compromis en gérant une branche d'écran par branche majeure de SPIP, dont on maintient la version N et N-1 uniquement ?

On aurait un écran pour SPIP-2 (déprécié et plus maintenu), un écran pour SPIP-3 que l'on continue à maintenir tant que l'on est en version 4 et un écran pour SPIP-4 (si tant est que cela a du sens).

Il est vrai que dans un passé récent les failles étant plus subtiles et sournoises il n'était pas possible de les bloquer via un simple prepend php et du coup l'écran a perdu de son intérêt...

L'intention initiale était d'avoir quelque chose de simple et compréhensible et facile à mettre à jour. D'où un seul et unique écran pour toutes les versions de SPIP. Je crains que versionner trop en détail rende toute les mises à jour cela illisibles, à tout le moins sans un mécanisme de mise à jour automatique du dit écran (ce qui avait été abordé puis mis en pause et jamais relancé). On pourrait peut-être faire un compromis en gérant une branche d'écran par branche majeure de SPIP, dont on maintient la version N et N-1 uniquement ? On aurait un écran pour SPIP-2 (déprécié et plus maintenu), un écran pour SPIP-3 que l'on continue à maintenir tant que l'on est en version 4 et un écran pour SPIP-4 (si tant est que cela a du sens). Il est vrai que dans un passé récent les failles étant plus subtiles et sournoises il n'était pas possible de les bloquer via un simple prepend php et du coup l'écran a perdu de son intérêt...
Poster
Owner

Faire une version par branche est aussi une bonne idée intéressante effectivement et peut être encore plus simple.

Et j’ai bien vu le code de mise à jour qui n’est plus actif depuis 7 ans dans mise_a_jour_ecran_securite(), vu que c’est reporté comme du code inatteignable :)

Faire une version par branche est aussi une bonne idée intéressante effectivement et peut être encore plus simple. Et j’ai bien vu le code de mise à jour qui n’est plus actif depuis 7 ans dans mise_a_jour_ecran_securite(), vu que c’est reporté comme du code inatteignable :)
Owner

Je vais dans le sens de la proposition de @cerdic et je pense même que pour SPIP 4.2 ou 5 on pourrait plus simplement se passer de l'écran dans SPIP.

Je vais dans le sens de la proposition de @cerdic et je pense même que pour SPIP 4.2 ou 5 on pourrait plus simplement se passer de l'écran dans SPIP.
Poster
Owner

Qu’entends-tu par "se passer" du coup ?

Il fait encore certaines choses actuellement cet écran tout de même (même si on lui enlève les vieilleries donc).

Qu’entends-tu par "se passer" du coup ? Il fait encore certaines choses actuellement cet écran tout de même (même si on lui enlève les vieilleries donc).

Par exemple il limite l'exploration des robots dans les paginations croisées ou en cas de surchauffe de la charge serveur... Il contraint les 'id_' à des valeurs entières...

Par exemple il limite l'exploration des robots dans les paginations croisées ou en cas de surchauffe de la charge serveur... Il contraint les 'id_' à des valeurs entières...

Parce que je trouve ce mécanisme génialement simple et efficace, je le conserverai en allant même un peu plus loin pour que ca reste facilement maintenable :

L'intention initiale était d'avoir quelque chose de simple et compréhensible et facile à mettre à jour. D'où un seul et unique écran pour toutes les versions de SPIP.

Conserver les tests génériques (bots, null byte, id_, etc) est à mon sens toujours d'actualité.

Par contre, je serais partisan de créer un répertoire écran_sécurité/ contenant un fichier pour chaque vulnérabilité corrigé avec une nomenclature simple du type :

YYYYMMJJ_patch.php : inclus sur toutes version
YYYYMMJJ_patch_spip3.php : inclus uniquement en v3
YYYYMMJJ_patch_spip4.php : inclus uniquement en v4

Et l'écran de sécurité réalisant les tests génériques inclurait ces patchs en fonction de la version du Spip.

Je crains que versionner trop en détail rende toute les mises à jour cela illisibles, à tout le moins sans un mécanisme de mise à jour automatique du dit écran (ce qui avait été abordé puis mis en pause et jamais relancé).

Avoir un job qui s'occupe de MAJ ce répertoire tout seul (avec une option pour activer/désactiver ce comportement). Ca pourrait prendre la forme d'un plugin-dist qui se MAJ tout seul ?

On pourrait peut-être faire un compromis en gérant une branche d'écran par branche majeure de SPIP, dont on maintient la version N et N-1 uniquement ?

On aurait un écran pour SPIP-2 (déprécié et plus maintenu), un écran pour SPIP-3 que l'on continue à maintenir tant que l'on est en version 4 et un écran pour SPIP-4 (si tant est que cela a du sens).

Il est vrai que dans un passé récent les failles étant plus subtiles et sournoises il n'était pas possible de les bloquer via un simple prepend php et du coup l'écran a perdu de son intérêt...

Si on prend les dernières injections de PHP via le plugins stats, l'écran de sécurité aurait très bien pu être utilisé non (en matchant page=statistiques... & id != int) ?

Ca reste des idées hein :-)

Parce que je trouve ce mécanisme génialement simple et efficace, je le conserverai en allant même un peu plus loin pour que ca reste facilement maintenable : > L'intention initiale était d'avoir quelque chose de simple et compréhensible et facile à mettre à jour. D'où un seul et unique écran pour toutes les versions de SPIP. > Conserver les tests génériques (bots, null byte, id_, etc) est à mon sens toujours d'actualité. Par contre, je serais partisan de créer un répertoire écran_sécurité/ contenant un fichier pour chaque vulnérabilité corrigé avec une nomenclature simple du type : YYYYMMJJ_patch.php : inclus sur toutes version YYYYMMJJ_patch_spip3.php : inclus uniquement en v3 YYYYMMJJ_patch_spip4.php : inclus uniquement en v4 Et l'écran de sécurité réalisant les tests génériques inclurait ces patchs en fonction de la version du Spip. > Je crains que versionner trop en détail rende toute les mises à jour cela illisibles, à tout le moins sans un mécanisme de mise à jour automatique du dit écran (ce qui avait été abordé puis mis en pause et jamais relancé). Avoir un job qui s'occupe de MAJ ce répertoire tout seul (avec une option pour activer/désactiver ce comportement). Ca pourrait prendre la forme d'un plugin-dist qui se MAJ tout seul ? > > On pourrait peut-être faire un compromis en gérant une branche d'écran par branche majeure de SPIP, dont on maintient la version N et N-1 uniquement ? > > On aurait un écran pour SPIP-2 (déprécié et plus maintenu), un écran pour SPIP-3 que l'on continue à maintenir tant que l'on est en version 4 et un écran pour SPIP-4 (si tant est que cela a du sens). > > Il est vrai que dans un passé récent les failles étant plus subtiles et sournoises il n'était pas possible de les bloquer via un simple prepend php et du coup l'écran a perdu de son intérêt... Si on prend les dernières injections de PHP via le plugins stats, l'écran de sécurité aurait très bien pu être utilisé non (en matchant page=statistiques... & id != int) ? Ca reste des idées hein :-)
Owner

Qu’entends-tu par "se passer" du coup ?

Il fait encore certaines choses actuellement cet écran tout de même (même si on lui enlève les vieilleries donc).

Je voulais dire que mis à part les trucs que tu listes comme à conserver et la protection des id_* l'écran ne sert à rien sur un SPIP à jour. Et comme on a tendance à ne plus y reporter/adapter les fixes de sécu, on pourrait se débarrasser de l'écran si les trucs à conserver étaient directement dans le core.

> Qu’entends-tu par "se passer" du coup ? > > Il fait encore certaines choses actuellement cet écran tout de même (même si on lui enlève les vieilleries donc). Je voulais dire que mis à part les trucs que tu listes comme à conserver et la protection des `id_*` l'écran ne sert à rien sur un SPIP à jour. Et comme on a tendance à ne plus y reporter/adapter les fixes de sécu, on pourrait se débarrasser de l'écran si les trucs à conserver étaient directement dans le core.

Juste un petit témoignage en tant qu'utilisateur :
J'ai toujours perçu l'écran de sécurité comme un gros avantage de SPIP par rapport à d'autres CMS, la possibilité d'apporter un hotfix aussi simplement que remplacer un fichier sans remettre en cause le reste du CMS ça a été un vrai luxe pendant toutes ces années. Dans mon cas (très particulier j'en conviens), une mise à jour de l'écran c'est 5 minute de travail, une mise à jour mineure de SPIP c'est une journée complète, voir plus.
La proposition de g0uZ me semble être pertinente, mais je peux comprendre que ce soit compliqué et chronophage de reporter la correction de chaque faille dans cet écran.

Juste un petit témoignage en tant qu'utilisateur : J'ai toujours perçu l'écran de sécurité comme un gros avantage de SPIP par rapport à d'autres CMS, la possibilité d'apporter un hotfix aussi simplement que remplacer un fichier sans remettre en cause le reste du CMS ça a été un vrai luxe pendant toutes ces années. Dans mon cas (très particulier j'en conviens), une mise à jour de l'écran c'est 5 minute de travail, une mise à jour mineure de SPIP c'est une journée complète, voir plus. La proposition de g0uZ me semble être pertinente, mais je peux comprendre que ce soit compliqué et chronophage de reporter la correction de chaque faille dans cet écran.
Owner

Je trouve que l'idée de @g0uZ de découper l'écran en patchs selon une nomenclature est bonne, néanmoins j'opterai pour un script de build qui construit un ecran constitué d'un unique php pour chaque version de SPIP pour garder la simplicité.

(aussi parce que faire les bons inclure a la volée serait couteux, et quand l'écran de sécurité démarre il ne sait pas quelle version de SPIP on est en train de lancer)

On aurait ainsi un dossier patchs/ dans lesquels on écrits les patchs en les prefixant d'un numero d'ordre de 00_ à 99_ puis la date, puis un nom genre

  • 00_00000000_init_et_detections_bots.php
  • ...
  • 20_20120516_fix_pagination_folle.php
  • ...
  • 98_00000000_die_si_raison.php
  • 99_00000000_load_regulation.php

Dans le cartouche PHPDoc de chaque Patch, une mention SPIP=[;4.0[ pour définir les versions concernées par chaque patch.

Et ensuite donc une commande spip-cli qui build un ecran_securite.php par version, que l'on range dans des dossiers spip2/, spip3/ et spip4/

On numéroterait les versions des écrans en les prefixant de la version SPIP concernée: SPIP2-1.4.1, SPIP3-1.4.1, SPIP4-1.4.1

Si on a besoin, pour des question de compat PHP, d'écrire le même patch dans 2 formes différentes, on fait une déclinaison comme par exemple

  • 20_20120516_fix_pagination_folle_php5-7.php
  • 20_20120516_fix_pagination_folle_php7-8.php

Et on fixe la branche SPIP concernée pour chaque declinaison

Je trouve que l'idée de @g0uZ de découper l'écran en patchs selon une nomenclature est bonne, néanmoins j'opterai pour un script de build qui construit un ecran constitué d'un unique php pour chaque version de SPIP pour garder la simplicité. (aussi parce que faire les bons inclure a la volée serait couteux, et quand l'écran de sécurité démarre il ne sait pas quelle version de SPIP on est en train de lancer) On aurait ainsi un dossier `patchs/` dans lesquels on écrits les patchs en les prefixant d'un numero d'ordre de `00_` à `99_` puis la date, puis un nom genre * `00_00000000_init_et_detections_bots.php` * ... * `20_20120516_fix_pagination_folle.php` * ... * `98_00000000_die_si_raison.php` * `99_00000000_load_regulation.php` Dans le cartouche PHPDoc de chaque Patch, une mention `SPIP=[;4.0[` pour définir les versions concernées par chaque patch. Et ensuite donc une commande spip-cli qui build un ecran_securite.php par version, que l'on range dans des dossiers `spip2/`, `spip3/` et `spip4/` On numéroterait les versions des écrans en les prefixant de la version SPIP concernée: `SPIP2-1.4.1`, `SPIP3-1.4.1`, `SPIP4-1.4.1` Si on a besoin, pour des question de compat PHP, d'écrire le même patch dans 2 formes différentes, on fait une déclinaison comme par exemple * `20_20120516_fix_pagination_folle_php5-7.php` * `20_20120516_fix_pagination_folle_php7-8.php` Et on fixe la branche SPIP concernée pour chaque declinaison

Il me semble qu'une part de l'écran devrait aller dans le core. Par exemple ce que j'ai évoqué plus haut : la limitation des robots dans les paginations croisées ou en cas de surcharge serveur, et la contrainte des 'id_' à des valeurs entières...

Débrayable par une ou plusieurs constantes (comme plein d'autres trucs).

Il me semble qu'une part de l'écran devrait aller dans le core. Par exemple ce que j'ai évoqué plus haut : la limitation des robots dans les paginations croisées ou en cas de surcharge serveur, et la contrainte des 'id_' à des valeurs entières... Débrayable par une ou plusieurs constantes (comme plein d'autres trucs).
Sign in to join this conversation.
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.