[spip-dev] sécurité (dernièrecouche)

Dev
1

Coucou,

je me demande si on ne devrait pas créer une page "sécurité" dans la config,
qui regrouperait :

    1) le choix des sessions unique/multiple (centralisé au niveau du site,
        au lieu d'être utilisateur par utilisateur comme maintenant, ce qui
        est absurde si on constate une attaque par "vol de cookie").
    ->> modifiable par tous admins ; annule et remplace le cadre "infos de
        sécurité" ; défaut = multiple

    2) la création ou non des fichiers .htpasswd et .htpasswd-admin
    ->> modifiable uniquement par auth ftp ; défaut = oui si le fichier
        existe déjà ou si on est en .htaccess

    3) la possibilité de recevoir son cookie de modif mot de passe par mail
    ->> modifiable par tous admins ; défaut = ok

    4) la désactivation du filtre de sécurité php/javascript sur les
        *articles publiés*
    ->> modifiable par ftp, défaut = activé

    5) ... j'en oublie ? ... un futur "activer wiki" feature spécial walk ...

Cet endroit serait aussi le bon emplacement pour des explications complètes.

-- Fil

2

je me demande si on ne devrait pas créer une page "sécurité" dans la config,

C'est en cours de programmation dans le CVS

qui regrouperait :

    1) le choix des sessions unique/multiple (centralisé au niveau du site,
        au lieu d'être utilisateur par utilisateur comme maintenant, ce qui
        est absurde si on constate une attaque par "vol de cookie").
    ->> modifiable par tous admins ; annule et remplace le cadre "infos de
        sécurité" ; défaut = multiple

Le réglage est prêt, mais il faut encore :
    -> l'appliquer à la connexion et au cookie tournant
    -> modifier "déconnecter" pour qu'il déconnecte toutes les sessions (je pense)

    2) la création ou non des fichiers .htpasswd et .htpasswd-admin
    ->> modifiable uniquement par auth ftp ; défaut = oui si le fichier
        existe déjà ou si on est en .htaccess

C'est fait.

    3) la possibilité de recevoir son cookie de modif mot de passe par mail
    ->> modifiable par tous admins ; défaut = ok

En fait ce cookie est déjà sécurisé, sauf si on n'a pas confiance en son
mail et qu'on ne se connecte jamais à son spip => faut-il vraiment un
réglage supplémentaire ?

    4) la désactivation du filtre de sécurité php/javascript sur les
        *articles publiés*
    ->> modifiable par ftp, défaut = activé

A la réflexion, mauvaise idée, puisqu'il s'agit, pour tout le monde,
d'adopter une tactique plus saine en matière de javascript : les mettre dans
une librairie fixe, et les appeler au cas par cas via des mots-clés
techniques...

-- Fil

3

Yo,

> qui regrouperait :
>
> 1) le choix des sessions unique/multiple (centralisé au niveau du site,
> au lieu d'être utilisateur par utilisateur comme maintenant, ce qui
> est absurde si on constate une attaque par "vol de cookie").
> ->> modifiable par tous admins ; annule et remplace le cadre "infos de
> sécurité" ; défaut = multiple

Le réglage était par utilisateur car ça pouvait faire chier
sur certains brouteurs (qui attrapaient mal le nouveau cookie
et déconnectaient intempestivement). Il faudrait donc que le
réglage par défaut puisse être modifié par utilisateur.

D'autre part je préférerais franchement défaut=simple, l'avertissement
systématique est vraiment casse-b* (et puis sinon tous les débutants
avec un brouteur sourcilleux vont être totalement désemparés). Je
verrais donc plutôt :

- si global=simple : les utilisateurs sont par défaut en sécurité
normale, avec avertissements seulement s'ils passent en sécu avancée

- si global=avancé : les utilisateurs sont par défaut en sécurité
avancée, et les avertissements continuent à être affichés s'ils
passent en sécu normale

Le réglage par défaut (global=simple) permet alors de régler une
bonne fois pour toutes le problème de ces rogntudjus d'avertissements,
sauf pour ceux qui ont vraiment envie de les avoir, et les sites
qui exigent un niveau de sécurité élevé (pas le site moyen ;-)).

(NB : même sous linux quand tu passes en root, on ne te dit pas
"attention vous avez 12 autres sessions ouvertes". Il faut lire
les logs pour ça.)

> 2) la création ou non des fichiers .htpasswd et .htpasswd-admin
> ->> modifiable uniquement par auth ftp ; défaut = oui si le fichier
> existe déjà ou si on est en .htaccess

Il faut défaut=non, à cause des serveurs qui ne gèrent pas les .htaccess
et ne protègent donc pas correctement ecrire/data (comme IIS, ou les
Apache réglés non-standard). De toute façon, les gens qui veulent un
.htpasswd sont capables de cocher une option ;-))

A la réflexion, mauvaise idée, puisqu'il s'agit, pour tout le monde,
d'adopter une tactique plus saine en matière de javascript : les mettre dans
une librairie fixe, et les appeler au cas par cas via des mots-clés
techniques...

Oui.

a+

Antoine.

4

D'autre part je préférerais franchement défaut=simple, l'avertissement
systématique est vraiment casse-b* (et puis sinon tous les débutants
avec un brouteur sourcilleux vont être totalement désemparés). Je
verrais donc plutôt :

- si global=simple : les utilisateurs sont par défaut en sécurité
normale, avec avertissements seulement s'ils passent en sécu avancée

- si global=avancé : les utilisateurs sont par défaut en sécurité
avancée, et les avertissements continuent à être affichés s'ils
passent en sécu normale

Le réglage par défaut (global=simple) permet alors de régler une
bonne fois pour toutes le problème de ces rogntudjus d'avertissements,
sauf pour ceux qui ont vraiment envie de les avoir, et les sites
qui exigent un niveau de sécurité élevé (pas le site moyen ;-)).

Oui, c'est con d'en être arrivés à une telle usine à gaz. Mea culpa.

Dans nos scénarios limite (ie "Gênes" et "vol de cookie via javascript"),
peut-être que tout est gérable par un simple message de logon (bonjour=oui)
disant : précédente connexion était de tel endroit à telle heure. Avec, en
cas d'attaque grave ou de recrudescence paranoiaque, la possibilité de virer
les sessions par ftp, puis d'alerter tout le monde sur le fait qu'il faut
vérifier le message de logon. Du coup on virerait tout ce pataquès de
zap_session... ?

-- Fil