Token , session et bug incompréhensible

**grunk** · 14/01/2011, 16h09

Bonjour à tous,

J'ai une classe me permettant de générer des "token" pour sécurisé divers appel à des formulaire ou des appels ajax.
Je n'avais jusqu'à maintenant jamais eu de problème. Or je viens de tester la classe sur un hébergement mutualisé et là c'est le drame !

Le concept : On arrive sur un formulaire , un token est généré, stocké en session puis plaer dans un input hidden.
Après soumission du formulaire , je vérifie si le token en session est équivalent à celui passé dans le formulaire.

Le problème : La valeur en session est modifiée entre le clic sur le bouton d'envoi et l'apparition de la page du coup le token n'est jamais le bon.

J'ai retourné le code dans tous les sens mais rien à faire. Un petit exemple simplifié ou je rencontre le problème :

Token.class.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
class Util_Token
{
	static public $error = 0;
 
	static public function genToken($ttl = 15)
	{
		if(!isset($_SESSION))
			throw new Exception("Une session doit être active");
 
 
		$gentoken 	= hash('sha1',uniqid(rand(),true));
		$rand 		= rand(1,20);
		$gentoken	= substr($gentoken,$rand,20);
		$ttl		*= 60;
 
		$_SESSION['csrf_protect'] = array('token'=>$gentoken,'ttl'=>$ttl);
 
		return $gentoken;
	}
 
	static public function checkToken()
	{
		if(!isset($_SESSION))
			throw new Exception("Une session doit être active");
 
		if($_REQUEST['csrf_protect'] == $_SESSION['csrf_protect']['token'])
			return true;
		else
			return false;
	}
}

index.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
session_start();
require('Token.class.php');
if(!empty($_POST) || !empty($_GET))
{
	echo 'Recu Form : '.$_POST['csrf_protect'].'<br />';
	echo 'Connu Session : '.$_SESSION['csrf_protect']['token'].' ttl : '.$_SESSION['csrf_protect']['ttl'].'<br />';
 
}
else
{
$token = Util_Token::genToken();
 
echo 'Généré : '.$token;
?>
<form action="index.php" method="post">
	<input type="text" value=" TEst" name="testtext">
	<input type="hidden" value="<?php echo $token; ?>" name="csrf_protect">
	<input type="submit" value="envoi" />
</form>
<?php
}
?>

En remplacant la chaine aléatoire du token par une date (H:i:s) j'ai remarqué que sur le serveur mutualisé il y'avais 1 sec de décalage entre la date recu et la date en session.

Note : En local je n'ai pas de problème avec ce code...

**RunCodePhp** · 15/01/2011, 13h12

Salut

D'abord, je n'est pas de solution, je ne vois pas trop la raison

Ca commence mal

Est ce que code que tu donne est un code simplifié de ce que tu as où est-ce réellement ce code que tu as ?

Il y a un truc où il me semble intéressant de confirmer, c'est est ce que lors de la création du token et de son affichage dans le champ caché les dates sont vraiment identiques ?
Ce qui laisserait supposer que ce serait vraiment lors de la récupération de celui-ci qui cause problème (le session_start).

Après ça, une idée comme ça pour débugger (donc provisoirement), il n'y aurait il pas moyen de rajouter un code dans la méthode genToken() qui écrirait dans un fichier par exemple afin de savoir l'heure exacte de chaque appel, mais surtout savoir combien de fois il y a eu d'appel.
Sait on jamais, cette méthode est peut être appelée 2 fois soit à une intervalle d'une seconde (qui modifierait sa valeur).
Un simple appel à error_log('une date') suffirait dans un tel cas.

Disons que, il serait bon d'avoir la certitude que c'est lors de l'appel à session_start() où le décalage à lieu.
Si décalage il y a, donc qu'au départ c'est bon puis après c'est plus bon, il y a forcément "écrasement" de cette valeur à un moment donné, non ?
(faut même souhaité que ce soit le cas, sinon c'est THE big bug, la grosse tuile même

)
Je me dis que dans tel cas, il faudrait repérer qui modifie cette variable "token" de session, voir la session elle même (le fichier).

Je me suis jamais trop posé ce genre de question, mais il y a t-il quelque part une trace (un log) de tout accès à un fichier, surtout s'il est modifié, comme entre autre les fichiers de sessions ? (Apache, Php, etc ... ?)

Puis à 200% au pif : As tu essayé de changer les valeurs des clés (csrf_protect, token) ?

Plutôt surprenant ce décalage, et particulièrement que ça marche en local et pas sur un mutualisé.

**grunk** · 17/01/2011, 09h24

Est ce que code que tu donne est un code simplifié de ce que tu as où est-ce réellement ce code que tu as ?

C'ets un code simplifié mais j'ai extrait que la partie qui pose problème. Le reste (méthode static) n'intervient pas dans le problème.

Comme tu le préconisais j'ai fait un trace dans un fichier texte. Code utilisé :

Token.class.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class Util_Token
{
	static public $error = 0;
 
	static public function genToken($ttl = 15)
	{
		if(!isset($_SESSION))
			throw new Exception("Une session doit être active");
 
			$gentoken 	= hash('sha1',uniqid(rand(),true));
			$rand 		= rand(1,20);
			$gentoken	= substr($gentoken,$rand,20);
			$ttl		*= 60;
			$h = fopen('test.txt','a+');
			fwrite($h,date("H:i:s").' :  '.$gentoken."\n");
			fclose($h);
			$_SESSION['csrf_protect'] = array('token'=>$gentoken,'ttl'=>$ttl);
 
			return $gentoken;
	}
}

index.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
session_start();
require('Token.class.php');
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
</head>
<body>
<?php
if(isset($_POST) && !empty($_POST))
{
	echo 'Recu Form : '.$_POST['csrf_protect'].'<br />';
	echo 'Connu Session : '.$_SESSION['csrf_protect']['token'].' ttl : '.$_SESSION['csrf_protect']['ttl'].'<br />';
 
}
else
{
	$token = Util_Token::genToken();
	echo 'Généré : '.$token;
	?>
	<form action="index.php" method="post">
		<input type="text" value=" TEst" name="testtext">
		<input type="hidden" value="<?php echo $token; ?>" name="csrf_protect">
		<input type="submit" value="envoi" />
	</form>
<?php
}
?>
</body>
</html>

Donc je peux pas faire plus basique.
En local et sur un dédié (Php 5.3.3) Mon fichier texte contient bien le résultat attendu :

08:35:15 - montokensupersecret

Par contre sur le mutualisé (ovh 5.2.14) j'hallucine complètement :

08:33:17 - montokensupersecret #Correspond au chargement normal de la page
08:33:17 - unautretoken
08:33:20 - encoreuntoken # correpsond à l'appui sur le bouton submit

Donc deux appels en trop qui sorte de nul part alors que le code utilisé est strictement identique.

J'avoue ne pas comprendre.

Edit ---
Testé sur un mutu 1and1 et le problème est présent également. LA seule différence entre les mutu et mon poste locale/serveur dédié c'est l'os (Linux pour les mutu , windows pour les dédiés)

Edit2 ----

Même le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
session_start();
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
</head>
<body>
<?php
if(isset($_POST) && !empty($_POST))
{
	echo 'Recu Form : '.$_POST['csrf_protect'].'<br />';
	echo 'Connu Session : '.$_SESSION['csrf_pro']['token'].' ttl : '.$_SESSION['csrf_pro']['ttl'].'<br />';
 
}
else
{
	/*require_once('Token.class.php');
	$token = Util_Token::genToken();*/
	function genToken()
	{
		$h = fopen('test.txt','a+');
		fwrite($h,date("H:i:s")."\n");
		fclose($h);
	}
	$qsd = genToken();
	?>
	<form action="index.php" method="post">
		<input type="text" value=" TEst" name="wxvxcvb">
		<input type="hidden" value="<?php echo $qsd; ?>" name="wxc">
		<input type="submit" value="envoi" />
	</form>
<?php
}
?>
</body>
</html>

Génère 3 lignes dans le fichiers texte ...

**RunCodePhp** · 17/01/2011, 10h04

C'est clairement bizarre.

Il y un truc où je n'ai pas de réel explication, mais cette condition me chiffonne un peu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if(!isset($_SESSION))

C'est peut être pas du tout le problème, mais pour exemple, de mon coté j'ai plutôt créé une méthode Session::isStarted() (true/false) qui me permets de vérifier si la session a bien démarrée.

Aussi, tu avais évoqué Ajax dans ton 1er post.
Du coup, n'y aurait il pas justement une vérification via Ajax des données saisie du formulaire, qui théoriquement initialiserait/démarrerait la session ?
Si tel est le cas, il y a peut être quelque chose de particulier (Ajax c'est déjà particulier).

Puis coté traçage (vu que je patauge aussi sur ce problème), personnellement je ferais en sorte d'y rajouter le nom de la page qui appel le script.
Histoire d'être certain que c'est cette page (ou vue) formulaire.

As tu relevé les logs coté Apache ?
N'y aurait il pas des requêtes HTTP envoyées comme ça anormalement ?

Vu que ça à l'air une question de version de Php, comme ça je me dis qu'il doit avoir une erreur pour cette version et pas sur celle en local.
Cette erreur provoquerait donc ces 2 appels de trop.
Mais alors quoi ???

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$ttl		*= 60;

Juste comme ça, je ne vois nulle par l'initialisation/déclaration de cette variable .ttl.
Théoriquement ça devrait provoquer une erreur, non ?
Je sais que ça n'a rien avoir, mais comme d'hab, sait on jamais.

Toujours pas de solution, j'en sais fichetre rien

**RunCodePhp** · 17/01/2011, 10h11

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

action="index.php"

Tiens donc ?
Ca me rappel quelque chose ça.

L'URL est elle vraiment comme ça : index.php
Essai de plutôt mettre comme ceci : /index.php, ou mettre une URL absolue complète.

Je n'entrerais pas dans les détails, mais j'ai eu un bug franchement tordu (et bien prise de tête) en exploitant justement des URLs comme ça (index.php) alors qu'en mettant le slash avant, plus du tout de problème.

Même crédo, sait on jamais.

**grunk** · 17/01/2011, 10h33

Aussi, tu avais évoqué Ajax dans ton 1er post.
Du coup, n'y aurait il pas justement une vérification via Ajax des données saisie du formulaire, qui théoriquement initialiserait/démarrerait la session ?

Dans mes tests je suis sur un simple formulaire pas d'ajax

Puis coté traçage (vu que je patauge aussi sur ce problème), personnellement je ferais en sorte d'y rajouter le nom de la page qui appel le script.
Histoire d'être certain que c'est cette page (ou vue) formulaire.

Bonne idée mais ca ne m'avance pas plus :

10:23:36 /labs/token/index.php
10:23:36 /labs/token/index.php
10:23:39 /labs/token/index.php

Tiens donc ?
Ca me rappel quelque chose ça.

L'URL est elle vraiment comme ça : index.php
Essai de plutôt mettre comme ceci : /index.php, ou mettre une URL absolue complète.

Déjà eu ce style de problème également mais là ca ne semble pas pose rde problème (les deux solutions rencontre le même souçis).

Si jamais certains peuvent tester ce simple bout de code et vérifié qu'il ne produit pas 3 lignes mais bien une seule :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
session_start();
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
</head>
<body>
<?php
if(isset($_POST) && !empty($_POST))
{
	echo 'Formulaire envoyé ,consulter fichier log';
 
}
else
{
	/*require_once('Token.class.php');
	$token = Util_Token::genToken();*/
	function genToken()
	{
		$h = fopen('test.txt','a+');
		fwrite($h,date("H:i:s").' '.$_SERVER['REQUEST_URI']."\n");
		fclose($h);
	}
	$qsd = genToken();
	?>
	<form action="index.php" method="post">
		<input type="text" value=" TEst" name="wxvxcvb">
		<input type="hidden" value="<?php echo $qsd; ?>" name="wxc">
		<input type="submit" value="envoi" />
	</form>
<?php
}
?>
</body>
</html>

**grunk** · 17/01/2011, 10h37

HA !

Je viens de trouver.
C'est Chrome qui pose problème. Avec IE et firefox aucun problème , le formulaire n'est soumis qu'une seule fois mais avec Chrome rien ne va plus et j'ai 3 soumissions.

Reste à comprendre pourquoi c'est le cas en ligne et pas en local ...

**RunCodePhp** · 17/01/2011, 15h02

Si jamais certains peuvent tester ce simple bout de code

Je viens d'essayer, et ma config est celle dans ma signature, donc entre autre Wamp/Php5.3.5.

Rien d'anormal, donc 1 seule soumission aussi bien sur FF que sur Chrome (8.0).

Je n'ai pas la possibilité de faire des test sur un serveur distant, pour la bonne raison que je n'ai plus rien depuis 3 mois.

Mais c'est pour mieux repartir. (mais tout ça n'a rien avoir

)

Bref, je ne vois toujours pas la source de ton problème.

Le seul truc, disons selon ma logique, si le problème se remarque selon le type de navigateur, c'est qu'à mon sens c'est lié au code HTML.
Certains navigateurs anticiperaient une erreur (la corrigerait en gros) alors que d'autres ça les déboussolent, ce qui peu expliquer les requêtes HTTP successives.

Ce qui m'interpelle, m'intrigue, c'est le nombre.
Pourquoi 2 autres inutiles, pourquoi pas 4, 5, voir 10 autres ?
Ce nombre de 2 serait forcément lié à des éléments dans cette page, ne crois tu pas ?

Du coup, et en suivant cette logique, je vois ces 2 éléments là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
<input type="text" value=" TEst" name="wxvxcvb">
<input type="hidden" value="<?php echo $qsd; ?>" name="wxc">

Normalement ces balises devraient finir comme ceci : /> selon la norme.

D'ailleurs, le doctype est HTML4, et non du HTML4 transitional,.
Le HTML4 ne serait il pas plus restrictif que du transitionnal ?
Puis Chrome étant assez récent comme navigateur, peut être n'apprécie il pas ce doctype, va savoir.
M'enfin, tout ça n'a peut être aucun rapport, c'est vraiment 100% au pif, d'autant plus que je ne suis pas parvenu à reproduire le phénomène.

Disons que j'essaie de comprendre aussi.

Il y a un autre truc quand même, c'est que la page n'a pas de <title>UN TITRE</title>
Même crédo, au pif.

Dernier point.
As tu essayé de voir avec le plugin FireBug sur FF pour voir d'un peu plus près ce problème.
Ca va peut être fournir une indication, une piste.
Pour mon problème, ce plugin m'a bien aidé à le comprendre.

**grunk** · 17/01/2011, 15h10

Ca n'a plus grand chose à voir avec du php mais je détail un peu

J'ai investigué un peu et en partant d'une page web basique (en gros la structure de base avec un texte dans la balise body ).
Aussi bien en Chrome 8 qu'en 9 j'ai un double appel de la page.

Un premier tout à fait normal et un second fait apparemment en ajax. Dans mes messages précédents le 3ème appel était du au clic sur le bouton.

Bref pour le moment pas réellement d'explication j'ai un autre pc avecun Chrome 6 qui n'a pas de problème mais la config matériel/ logiciel n'étant pas la même je peux pas déduire d'ou viens le problème.

Pour ceux que ca intéresse ou qui on le même problème j'ai ouvert un ticke tde bug pour chromium : http://code.google.com/p/chromium/is...etail?id=69869
avec les extraits des entête http ainsi qu'une capture d'écran des requête réseau

**Sayrus** · 31/05/2011, 10h00

Salut Grunk,

Ce n'est pas lié à chrome, j'ai exactement le même problème sous FF, hors j'ai procédé à tous les tests possibles et inimaginable et je suis à 100% certains que ma méthode de création de session est bonne!

Pas d'ajax, pas de double appel de page, tout semble normal et pourtant la session change alors qu'elle ne devrait pas!

As-tu trouvé une explication finalement?

**Sayrus** · 31/05/2011, 10h24

Je peux également dire que la théorie des balises mal fermées, etc est à exclure car ma page est valide XHTML Strict et aucune erreur.

Pourtant l'erreur de token persiste...

**grunk** · 31/05/2011, 10h54

Non pas plus d'explication mais comme le problème ne semblait se produire que sur un hébergement particulier (1&1 de mémoire) j'ai fini par me dire que ça venait de là ... mais encore une fois ce n'est que supposition.

**Sayrus** · 31/05/2011, 11h27

Il y a une explication, le tout c'est de la trouver...

Pas évident...

**Sayrus** · 31/05/2011, 17h06

Il n'y a pas un expert PHP susceptible d'apporter une solution à cette intrigant problème?

**Sayrus** · 04/06/2011, 15h07

Bon ça y est j'ai trouvé une demi heure de temps pour me pencher sur le problème.

Comme je ne savais pas d'où venait le problème, j'ai d'abord tester pour voir si il y avait des appels HTTP multiples à ma page via le script PHP suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$fp=fopen(mt_rand().'.txt', 'w+');
fclose($fp);
die('ok');

Je place ce script, je me rend compte que ma page est quand même executée 2x car il y a bien à la racine 2 répertoires générés!!! (Attention je rappelle qu'il n'y a même pas d'appel Ajax)

Ce que j'ai fait, j'ai pris mon courage a deux mains et placé au début du fichier en parcourant petit à petit les profondeurs des includes jusqu'à ce que le code PHP ci-dessus m'écrive à la racine 2 fichiers, signe d'un bug...

Et bien j'ai trouvé le bug!

Vous saviez ce que c'était? Un appel à un fichier js qui n'était plus présent sur le répertoire du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<script type="text/javascript" src="js/monfichiermanquant.js"></script>

Du fait que ce fichier n'existait plus, 2 requêtes étaient executées et provoquait l'erreur de token!

Pourquoi ça fait ça? Je ne sais pas le dire! Mais c'est bien l'erreur produite!

En espérant que ça en aide plus d'un!

**grunk** · 04/06/2011, 15h22

Bien vu !

**Setzer59600** · 26/01/2013, 15h08

Comme le sujet n'est pas en résolut , j'ai ptet une petite idée

j'ai eu un problème similaire lors d'appel de script jquery avec le session_start :

l'id de session changeait lorsque j'appelais un fichier php contenant un script jquery, alors que je n'y faisait qu'a peine référence.... ce qui n'est pas ultra pratique ni logique

je me suis aperçu (après de nombreux tests

) que c'était la variable de récupération dans le script php appelé qui modifiait la valeur de la variable dans la session

une petite explication :

script appelant:

<a href="#?i=1" class="Artisants__voir bouton_action"><img src="ui/icones/voir.png" title="Voir" width="24">Voir</a>

// voir
$(".Artisants__voir").click(function(){
var id=this.href.split(/(.+)i=([^&]+)/)[2];
var link="t='.$tab.'&i="+id;
alert("voir appuyé = "+link);
$.ajax({
type:"POST",
url:"'.$config['path']['jquery'].'/moteur/Detail.php",
data:link,
success:function(data){ $("#Artisants_Core").html(data); }
});
});

et dans le script appelé (Detail.php) :

if (isset($_POST['i'])){$id=$_POST['i'];}

là tout partait de travers et l'id de session devenait égal à l'id de l'item visité
j'ai juste changé le nom de la variable de récupération

if (isset($_POST['i'])){$i=$_POST['i'];}

et la plus de problème

En espérant que ca puisse à certain de résoudre ce bug étonnant

Token , session et bug incompréhensible [PHP 5.3]

Langage PHP

Discussions similaires

Partager

Partager