[spip-dev] deux r\xe9flexions

Dev
1

Deux réflexions ce matin :

1) Pour les accents, au lieu de donner leur code ascii en numérique (via
   chr(212)), on peut en fait les donner en hexa (plus "lisible", surtout
   si on est habitué au Quoted-Printable) :

   au lieu de
    <?php echo "J'ai bien mang".chr(212); ?>
   
   on peut préférer
    <?php echo "J'ai bien mang\xe9"; ?>

2) Pour l'histoire des zap_sessions, je vais proposer un changement qui à
    mon avis répondra aux attentes des trois développeurs. Je vais essayer
    d'expliquer la démarche, pour avoir vos commentaires, mais je coderai
    plus tard.

    - d'abord, se débarrasser du truc d'environnement basé sur le
    navigateur : c'est idiot, si quelqu'un me chourave mon cookie,
    il peut tout aussi bien me chouraver ma chaîne navigateur.

    - remplacer ce truc par un cookie "environnement" (spip_browser)
    aléatoire posé une fois pour toutes (un an) sur le brouteur. C'est
    un identifiant unique du brouteur. Au moment où on le pose, on vérifie
    du même coup que le navigateur accepte les cookies (sinon on passe
    en auth_http).

    - au moment du zap_session (login réussi ou affichage des infos
    sécurités), zapper systématiquement et silencieusement les (autres)
    sessions ayant le même cookie spip_browser (par définition, ce sont
    soit des sessions qui traînent suite à l'oubli de se déloguer DEPUIS LE
    MEME NAVIGATEUR, soit le produit d'un vol de cookie). Ainsi la sécurité
    contre vol de cookie est assurée.

    - Du coup l'explication pour les zap_session est plus simple : "Un autre
    navigateur est actuellement autorisé à se connecter sans renouveller son
    identification [aide] [bloquer cette connexion] [ne jamais accepter de
    connexions parallèles]" (mettre au pluriel et préciser le nombre de
    zap_sessions si besoin).

    Le bouton "[ne jamais accepter de connexions parallèles]" correspondra à
    un réglage auteur (via $prefs[]) et sera annulable dans "afficher les
    infos de sécurité" (pas au login, du coup, mais avec le bouton sous la
    fiche auteur)

    Enfin, ce bouton "afficher les infos de sécu" pourrait se trouver au
    niveau de auteur_infos plutôt que sur la page d'accueil.

-- Fil

2

   on peut préférer
    <?php echo "J'ai bien mang\xe9"; ?>

Si c'est plus lisible pour toi, ok :wink:

    - d'abord, se débarrasser du truc d'environnement basé sur le
    navigateur : c'est idiot, si quelqu'un me chourave mon cookie,
    il peut tout aussi bien me chouraver ma chaîne navigateur.

OK.

    - remplacer ce truc par un cookie "environnement" (spip_browser)
    aléatoire posé une fois pour toutes (un an) sur le brouteur. C'est
    un identifiant unique du brouteur. Au moment où on le pose, on vérifie
    du même coup que le navigateur accepte les cookies (sinon on passe
    en auth_http).

Non, pas d'identifiant unique permanent, pitié.

    - au moment du zap_session (login réussi ou affichage des infos
    sécurités), zapper systématiquement et silencieusement les (autres)
    sessions ayant le même cookie spip_browser (par définition, ce sont
    soit des sessions qui traînent suite à l'oubli de se déloguer DEPUIS LE
    MEME NAVIGATEUR, soit le produit d'un vol de cookie). Ainsi la sécurité
    contre vol de cookie est assurée.

Je ne comprends pas :
- si c'est une session depuis le même navigateur, quel intérêt de la tuer ?
- si je te vole un cookie (quelle horreur), je vais prendre le cookie
session, pas le cookie flicage
- le zap_session s'occupe déjà des "problèmes" de "vol de cookie" (sans
compter le jajascript rotatif), c'est quoi l'intérêt de rajouter une couche
inutile qui se déclenche exactement au même moment ?

De toute façon, le mot de passe est toujours en clair à l'install. Et
j'aimerais bien qu'on m'explique quel est le danger actuel. Aussi, en
quoi les articles voués à la publication sont des infos ultra-sensibles
au point de construire une usine à gaz ingérable.

> 2) Pour l'histoire des zap_sessions, je vais proposer un changement qui à
> mon avis répondra aux attentes des trois développeurs. Je vais essayer

Une de mes attentes est que ça reste simple. On est déjà à un niveau de
complexité inhabituel, pas besoin d'en rajouter.

3

Non, pas d'identifiant unique permanent, pitié.

Pour quelle raison ? Crainte du flicage ? Si c'est le cas, je ne crois pas
que ce que je propose soit plus fliquant que ce qui existe déjà.

> - au moment du zap_session (login réussi ou affichage des infos
> sécurités), zapper systématiquement et silencieusement les (autres)
> sessions ayant le même cookie spip_browser (par définition, ce sont
> soit des sessions qui traînent suite à l'oubli de se déloguer DEPUIS LE
> MEME NAVIGATEUR, soit le produit d'un vol de cookie). Ainsi la sécurité
> contre vol de cookie est assurée.

Je ne comprends pas :
- si c'est une session depuis le même navigateur, quel intérêt de la tuer ?

Si tu m'as volé mon cookie spip_browser, je tue la session directement ;
logique.

- si je te vole un cookie (quelle horreur), je vais prendre le cookie
session, pas le cookie flicage

Tu prendras les deux, sinon tu ne m'auras pas. Tu vois bien :wink:

- le zap_session s'occupe déjà des "problèmes" de "vol de cookie" (sans
compter le jajascript rotatif), c'est quoi l'intérêt de rajouter une couche
inutile qui se déclenche exactement au même moment ?

L'idée c'est de simplifier et d'améliorer, l'existant est assez lourd en
fait, je le reconnais bien volontiers. Le jaja rotatif est un pis-aller
temporaire j'espère.

De toute façon, le mot de passe est toujours en clair à l'install.

Oui, mais c'est un problème indépendant.

Et j'aimerais bien qu'on m'explique quel est le danger actuel. Aussi, en
quoi les articles voués à la publication sont des infos ultra-sensibles au
point de construire une usine à gaz ingérable.

Si un visiteur peut poster un message sur un forum public, message qui lui
permet de devenir admin, c'est un trou inacceptable : en effet il peut alors
aller modifier en douce des données dans un article, et écrire ensuite
"regardez il y a un article pédonazi sur uZine!", preuve à l'appui.

> 2) Pour l'histoire des zap_sessions, je vais proposer un changement qui à
> mon avis répondra aux attentes des trois développeurs. Je vais essayer

Une de mes attentes est que ça reste simple. On est déjà à un niveau de
complexité inhabituel, pas besoin d'en rajouter.

Justement, j'essaie de simplifier, c'est aussi pour ça que je reprends tout;
du coup des questions reviennent : je peux bricoler dans mon coin si tu
préfères, hein :wink:

A mon avis, donc, cette proposition simplifiera notablement le jargon
utilisé actuellement dans "afficher les infos de sécurité", et permettra
peut-être de se passer aussi du cookie rotatif (qui d'ailleurs n'a pas l'air
de fonctionner en ce moment). En plus ça m'amuse d'essayer d'aller au bout
de cette logique !

-- Fil

4

@ Fil <fil@rezo.net> :

peut-être de se passer aussi du cookie rotatif (qui d'ailleurs n'a pas
l'air de fonctionner en ce moment)

Je confirme que c'est problématique : visiblement sur mon brouteur l'image
retournée par le cookie rotatif reste en cache -- si je veux que ça marche
je dois mettre un URL rotatif aussi !

Il faudra vraiment trouver autre chose...

-- Fil

5

@ Fil <fil@rezo.net> :

> Non, pas d'identifiant unique permanent, pitié.

Pour quelle raison ? Crainte du flicage ? Si c'est le cas, je ne crois pas
que ce que je propose soit plus fliquant que ce qui existe déjà.

Bon, on peut faire aussi sans ce cookie supplémentaire : il suffit de mettre
l'id_browser dans le cookie de session ; il y a déjà l'id_auteur, pas
compliqué d'ajouter un petit numéro aléatoire qui sera conservé lors des
rotations de l'id_session (mais pas lorsqu'on se déloge).

L'avantage que je voyais à ce cookie longue durée, c'était de valider
"accepte les cookies" sans avoir à faire un redirect de plus (je suis clair,
là? non : avant de te proposer une auth_http, il faut que le login essaie
(1er hit) de te poser un cookie, puis vérifier (2nd hit) que le cookie a
bien été posé. Mais c'est cool : en plaçant login.php3 à la racine on va
grandement diminuer les redirect, on peut conserver celui-ci.

-- Fil

6

@ Fil <fil@rezo.net> :

Bon, on peut faire aussi sans ce cookie supplémentaire : il suffit de mettre
l'id_browser dans le cookie de session ; il y a déjà l'id_auteur, pas
compliqué d'ajouter un petit numéro aléatoire qui sera conservé lors des
rotations de l'id_session (mais pas lorsqu'on se déloge).

Euh, non, ça ne marche pas, je n'avais pensé qu'à la moitié des situations.
Je vais essayer de bricoler dans mon coin avant de revenir sur la liste :wink:

-- Fil

7

De toute façon, le mot de passe est toujours en clair à l'install.

Oui, mais c'est un problème indépendant.

Oui, mais autant ne pas mettre la charrue avant les boeufs :))))

Si un visiteur peut poster un message sur un forum public, message qui lui
permet de devenir admin, c'est un trou inacceptable : en effet il peut alors
aller modifier en douce des données dans un article, et écrire ensuite
"regardez il y a un article pédonazi sur uZine!", preuve à l'appui.

Et preuve à l'appui on peut démontrer que le site a été piraté. Je
sais bien qu'il y a des risques (théoriques : il n'y a jamais eu
une seule attaque sur uzine), mais chercher à s'en prémunir à tout
prix est plutôt... malsain non ?

Je confirme que c'est problématique : visiblement sur mon brouteur l'image
retournée par le cookie rotatif reste en cache -- si je veux que ça marche
je dois mettre un URL rotatif aussi !

On peut blinder les headers en passant aussi :

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
                                                      // always modified
header("Cache-Control: no-store, no-cache, must-revalidate"); // HTTP/1.1
header("Pragma: no-cache"); // HTTP/1.0

(tiré de la doc PHP)

NB : perso, les redirects ne me gênent pas trop....

8

Oui, mais autant ne pas mettre la charrue avant les boeufs :))))

plutôt tendance à creuser mon sillon

Et preuve à l'appui on peut démontrer que le site a été piraté.

Je préfère être capable de dépister le problème en amont (ou, mieux, de
l'empêcher carrrément) ! C'est autour de ça qu'on tourne depuis le début,
et qu'on appelle "problème du vol de cookie".

Une tout autre piste serait de blinder l'affichage des forums en leur
appliquant supprimer_tags() avant de les passer dans propre(). Ca aurait un
impact sur ce qui peut s'afficher dans les forums (pas de <br>, pas de
couleurs psychédéliques, etc. : mais est-ce un avantage ou un inconvénient ?)

L'idéal serait dêtre capable de désactiver jaja : soit "dans la suite de la
page" (pas bon pour les forums publics d'uZine qui utilisent jaja), soit
"jusqu'au tag XXXX"... Y'a-t-il des connaisseurs de javascript qui sauraient
faire ?

Je sais bien qu'il y a des risques (théoriques : il n'y a jamais eu une
seule attaque sur uzine), mais chercher à s'en prémunir à tout prix est
plutôt... malsain non ?

On parle de spip et des quelques centaines de sites qui tournent avec.

On peut blinder les headers en passant aussi :

J'essaie... marche pas. La session est rejouée 3 ou 4 fois, et puis ça
s'arrête. Etonnant !

NB : perso, les redirects ne me gênent pas trop....

Ca ne contribue ni à la lisibilité du code ni à son adaptation. Si on peut
faire sans, c'est préférable.

-- Fil

9

On parle de spip et des quelques centaines de sites qui tournent avec.

SPIP est largement plus sûr que phpnuke, qui est une passoire sans
que beaucoup de sites aient été touchés. On se complique surtout
les choses pour rien du tout. L'insécurité zéro n'existe pas, et la
paranoia n'est pas un climat agréable.

Pour l'instant on a un code d'authentification qui est relativement
sûr, je pense qu'on devrait laisser mûrir un peu (sauf pour le mot
de passe lors de l'install).

L'idéal serait surtout que d'autres personnes que nous regardent
le code, là on tourne en rond autour de quelques idées fixes.

10

la paranoia n'est pas un climat agréable.

C'est pas tant de la paranoïa que le déplaisir de connaître (en théorie)
une méthode d'attaque qu'on ne sait pas éviter. Une sorte de scrupule
perfectionniste, qui conduit en effet à la prise de tête.

Pour l'instant on a un code d'authentification qui est relativement sûr

Il lui manque encore des bouts (notamment pour les forums sur abonnement).
En fait, si je déplace pas mal de code en ce moment, j'en crée très peu...
Le fait de tout remonter vers le répertoire racine n'est une étape
nécessaire à la simplification du truc.

-- Fil

11

Alors super gaffe aux Macs/PCwinwin/Unices

Ils ne codent pas tous pareil... sauf si tu lui explique poliment le
charset.

Tiens, à ce propos, le charset europe actuellement valide, c'est le iso8859-15.
Le iso-8859-1 encore universellement utilisé est
périmé depuis... pfiou... 4 ans (à cause de l'euro) et remplacé par le
-15 que j'utilise et qui emm* le monde.

A+

12

Oui, c'est un bug Outlook qui ne reconnaît (toujours) pas le
iso-8859-15...