Sécurité... j'ai reçu çà

[Pepper]

Yo,

J'ai reçu un mail de PHPLizardo

http://img29.xooimage.com/files/e/7/f/plume-cms-1.2.3--...-de-code-1584025.pdf

Je vous laisse lire, perso pas le temps de corriger.

A+
Ced

[Loic d'Anterroches]

Que des cas connus. Il faudrait fixer cela en effet, mais je pense que
cela n'arrivera qu'avec le jour oů je vais porter xhtml.net sur Pluf et
recoded Plume pour utiliser Pluf.

loďc

[Jojaba]

Loic d'Anterroches a écrit :

Pepper wrote:
  

Yo,

J'ai reçu un mail de PHPLizardo

http://img29.xooimage.com/files/e/7/f/plume-cms-1.2.3--...-de-code-1584025.pdf

Je vous laisse lire, perso pas le temps de corriger.
    

Que des cas connus. Il faudrait fixer cela en effet, mais je pense que
cela n'arrivera qu'avec le jour où je vais porter xhtml.net sur Pluf et
recoded Plume pour utiliser Pluf.

loïc

  

Dans le document, presque toutes les failles sont proposées avec des solutions qui ne me semblent pas trop complexes à mettre en place. Dois-je modifier les fichiers incriminés en conséquence ?
Après ça on pourrait (dès que j'ai un peu plus de temps) mettre à dispo une nouvelle version comme cadeau de Noël :-P .

[Loic d'Anterroches]

Avec grand plaisir. Il y a juste un point difficile et je pensais à
celui-là. C'est le dernier. Le problème de la non authentification de la
source de la requête. Mais pour tout le reste c'est ok!

loïc

[Jojaba]

Loic d'Anterroches a écrit :

 Il y a juste un point difficile et je pensais à
celui-là. C'est le dernier. Le problème de la non authentification de la
source de la requête. Mais pour tout le reste c'est ok!

loïc

  

Je me suis documenté sur ce point (en fait j'ai cliqué sur la première ressource proposée par Google sur le sujet) : http://www.journaldunet.com/developpeur/tutoriel/php/031030php_nexen-xss3.shtml
Voici ce qui y est dit concernant la mise en place de ce type de jeton :

---

4. Obligez l'utilisateur à utiliser vos formulaires HTML

Le coeur du problème de CSRF est qu'une requête falsifiée peut imiter un formulaire. Si vous pouvez, de quelque manière que ce soit, déterminer si votre propre page web a été utilisée pour soumettre le formulaire, vous pouvez pratiquement éliminer le risque d'une attaque un CSRF. Après tout, si l'utilisateur n'a pas demandé le formulaire récemment, pourquoi un formulaire venant de cet utilisateur serait considéré comme valide ? C'est, bien sûr, plus facile à dire qu'à faire, mais il y a quelques moyens techniques pour le faire. Mes techniques préférées sont celles qui impliquent un secret partagé entre le serveur et l'utilisateur légitime. Par exemple, étudiez le listing 3 comme un remplacement du formulaire utilisé pour poster un message sur forum.exemple.org.

<?php
  $token = md5(time());
  $_SESSION['token'] = $token;
  $_SESSION['token_timestamp'] = time();
?>
<form action="/developpeur/add_post.php" method="post">
  <input type="hidden" name="token" value="<? echo $token; ?>" />
  <p>Subject: <input type="text" name="post_subject" /></p>
  <p>Message: <textarea name="post_message"></textarea></p>
  <p><input type="submit" value="Add Post" /></p>
</form>

A chaque fois qu'un utilisateur demande ce formulaire, une nouvelle marque est générée et cette marque est sauvegardée sur le serveur (dans la session de l'utilisateur, remplaçant les précédentes) et incluse dans le formulaire comme une variable cachée du formulaire. Ainsi, quand un message est posté, non seulement la marque est comparée à celle de la session de l'utilisateur, mais un temps mort peut également être appliqué pour minimiser davantage le risque. Cette tactique rend une attaque CSRF extrêmement difficile et par conséquent représente un fort niveau de protection.

---

C'est la bonne voie ?
Il faudrait dans ce cas, ajouter lors de l'identification de l'administrateur (je suppose que c'est ce code en haut de la page users.php : "auth::checkAuth(PX_AUTH_ADMIN);") les données de session proposées dans l'exemple (partie php) puis d'ajouter un champ de type "hidden" dans le formulaire de soumission permettant ensuite dans le code de traitement de la page de comparer les deux "jetons" avant d'envoyer les modifications apportées (ou lors d'une création de compte).
Je me demande d'ailleurs, s'il n'est pas plus simple d'ajouter les données de session directement dans la page users.php...
Mon résonnement est-il correct ?

[Loic d'Anterroches]

Jojaba,

ton approche est la bonne, par contre ton token est facile à "trouver",
tu peux commencer avec celui-là et ensuite je trouverai une solution
plus robuste.

loïc

Jojaba wrote:
> Loic d'Anterroches a écrit :
>> Il y a juste un point difficile et je pensais à
>> celui-là. C'est le dernier. Le problème de la non authentification de la
>> source de la requête. Mais pour tout le reste c'est ok!
>>
>> loïc
>>
>>
> Je me suis documenté sur ce point (en fait j'ai cliqué sur la première ressource
> proposée par Google sur le sujet) :
> http://www.journaldunet.com/developpeur/tutoriel/php/031030php_nexen-xss3.shtml
> Voici ce qui y est dit concernant la mise en place de ce type de jeton :

> --------------------------------------------------------------------------------
> */4. Obligez l'utilisateur à utiliser vos formulaires HTML /*

> --------------------------------------------------------------------------------

[Jojaba]

Loic d'Anterroches a écrit :

> Jojaba,
>
> ton approche est la bonne, par contre ton token est facile à "trouver",
> tu peux commencer avec celui-là et ensuite je trouverai une solution
> plus robuste.
>
> loïc
>
>

Petit hors-sujet. J'ai installé la version dans le dépot par-dessus une
ancienne version j'avais utilisée en locale pour test. J'ai des erreurs
dans aletcom. Je sais d'où ça vient. Les lignes que j'ai ajouté dans le
config.php se retrouvent dans le fichier config-dist.php (et donc ne
sont pas ajoutées au fichier de configuration de l'installation mise à
jour). C'est un problème que j'avais déjà évoqué d'ailleurs. Comment je
fais pour faire ajouter ces lignes dans le config.php ?

[Jojaba]

Concernant mon souci ci-dessus, il faut que j'ajoute des lignes dans
manager/install/upgrade.php c'est ça ? Juste pour confirmation. Je pense
pouvoir me débrouiller en m'inspirant de ce qui est déjà dans ce fichier...

[Loic d'Anterroches]

Exactement. Tu dois pouvoir retrouver quand j'ai fait l'ajout des codes
pour l'antispam.

loïc

> >

[Jojaba]

Loic d'Anterroches a écrit :

Jojaba wrote:
  

OK, ça fonctionne ! Je continue avec la faille à présent... :-)

[Jojaba]

Loic d'Anterroches a écrit :

Jojaba,

ton approche est la bonne, par contre ton token est facile à "trouver",
tu peux commencer avec celui-là et ensuite je trouverai une solution
plus robuste.
  

Petit retour sur le sujet effectif de ce post. Je viens de terminer de mettre en place le jeton (token). J'ai testé, apparemment ça fonctionne (en tout cas, j'arrive à modifier/créer des utilisateurs en local). Explication de ce que j'ai fait (tout se passe dans le fichier "../manager/users.php".
En début du fichier j'ai placé le code suivant (ligne 32 à 37) :
//To improve security, defining a token
if (empty($_POST['save'])) {


    $token = md5(time());
    $_SESSION['token'] = $token;
    $_SESSION['token_timestamp'] = time();
}

Ensuite dans le fragment de code permettant de vérifier et valider les données provenant du formulaire (ligne 114 à 175) j'ai ajouté ceci (ligne 115 à 118) :
 //Verifying token for security reasons
    $token = $_POST['token'];
    $delay = time() - $_SESSION['token_timestamp'];
    if ($token == $_SESSION['token'] && $delay > 5):

et à la fin du fragment de vérification et validation des données (juste avant la dernière accolade) j'ai terminé par un :
endif;

Dans le formulaire de soumission j'ai ajouté le code suivant (ligne 303 à 304) :
//To improve security
  echo form::hidden('token', $token);

Pour expliquer ce qui se passe (en tout cas, ce que je pense qui se passe :-P ) :
Un jeton est créé au chargement de la page (et uniquement au chargement ce qui explique le test qui permet de savoir si le formulaire a été validéé ou pas). Ensuite, lors de l'envoi du formulaire, on vérifie d'une part que le token envoyé par le champ invisible et celui contenu dans les données de session de l'administrateur sont les même et d'autre part si un laps de temps de 5 secondes s'est déroulé entre le chargement de la page et l'envoi du formulaire (à ce propos, je ne sais pas si c'est utile de mettre un délai aussi important, j'aurai aussi pu simplement tester si le chargement de la page et la soumission n'ont pas été simultanés, vous me dites ce qu'il est préférable de faire, hein...). ces 5 secondes sont un peu longue lorsqu'on veut simplement supprimer une donnée, ça pourrait être déroutant pour ceux qui ne savent pas qu'on a mis un tel système en place, puisque si le délai est inférieur à 5 secondes, les modifications opérées ne seront pas prises en compte. Dois-je raccourcir le délai ?

Juste pour être certain de ne pas avoir fait de bêtise... ;-)

[Loic d'Anterroches]

Tu peux enlever le timeout mais avoir un token robuste comme cela:

$token = md5(microtime().config::f('secret_key').$_COOKIE['px_session']);

loïc

[Jojaba]

Loic d'Anterroches a écrit :

Tu peux enlever le timeout mais avoir un token robuste comme cela:

$token = md5(microtime().config::f('secret_key').$_COOKIE['px_session']);


  

OK, je m'en occupes tout de suite. ;-)

[Jérémie [ kiwii ]]

Salut,
Le "htmlspecialchars" n'est pas bien placé il faut le mettre comme
suit dans
/mtemplates/_top.php

if(!empty($_GET['msg'])) {
$msg = htmlspecialchars($_GET['msg']);
} else {
$msg = $m->getMessage();
}
if (!empty($msg)) {
echo '<p class="message">'.$msg.'</p>';
}

Sinon, le lien "Valider et mettre en ligne l'article" n'est plus un
lien à cause de la transformation.

Et dans /manager/xmedia.php j'ai passé le $env à :

$env = (!empty($_GET['env'])) ? intval($_GET['env']) : 1;

On 26 nov, 12:59, Jojaba <joj...@gmail.com> wrote:
> Loic d'Anterroches a écrit :Pepper wrote:Yo, J'ai reçu un mail de PHPLizardohttp://img29.xooimage.com/files/e/7/f/plume-cms-1.2.3--...-de-code-1584025.pdfJe vous laisse lire, perso pas le temps de corriger.Que des cas connus. Il faudrait fixer cela en effet, mais je pense que cela n'arrivera qu'avec le jour où je vais porter xhtml.net sur Pluf et recoded Plume pour utiliser Pluf. loïcDans le document, presque toutes les failles sont proposées avec des solutions qui ne me semblent pas trop complexes à mettre en place. Dois-je modifier les fichiers incriminés en conséquence ?

[Jojaba]

Le 30/12/2009 13:01, J�r�mie [ kiwii ] a �crit :
> Salut,
> Le "htmlspecialchars" n'est pas bien plac� il faut le mettre comme

> suit dans
> /mtemplates/_top.php
>
> if(!empty($_GET['msg'])) {
> $msg = htmlspecialchars($_GET['msg']);
> } else {
> $msg = $m->getMessage();
> }
> if (!empty($msg)) {
> echo '<p class="message">'.$msg.'</p>';
> }
>
> Sinon, le lien "Valider et mettre en ligne l'article" n'est plus un

> lien � cause de la transformation.
>
> Et dans /manager/xmedia.php j'ai pass� le $env � :

>
> $env = (!empty($_GET['env'])) ? intval($_GET['env']) : 1;
>
>

Merci J�r�mie !
J'ai fait les modifs dans le "trunk". On va encore attendre un peu avant
de publier une version 1.2.4.1 avec les diff�rentes corrections (mauvais
num�ro de version, tes propositions kiwii), qu'en penses-tu Lo�c ?