Forum d'entraide PHPFrance

Salut à tous

j'ai fait un formulaire sur plusieurs pages en php qui utilise des variables de session afin de sauver les valeur de post de mes champs...

vue que certaines de ces variables sont relativement sensible, j'ai fait en sorte de les crypter avant de les passées en session...

Cela fonctionne à merveille sur mon PC via easyPHP mais une fois uploder chez mon hebergeur, j'ai de gros problème:

Warning: mcrypt_encrypt(): The IV parameter must be as long as the blocksize in /home/www/user/www/form2.php on line 301
Warning: mcrypt_encrypt(): The IV parameter must be as long as the blocksize in /home/www/user/www/form2.php on line 301
Warning: mcrypt_encrypt(): The IV parameter must be as long as the blocksize in /home/www/user/www/form2.php on line 301

voici le passage de code correspondant à l'erreur:

// On crypt et on sauve les variables en session pour retour vers le formulaire
$list_variable = array('champ1', 'champ2', 'champ3');
foreach($list_variable as $nom_var)
{
   if(${"${nom_var}"} != '')
   {
       $_SESSION["${nom_var}"] = mcrypt_encrypt($algo, $cle, ${"${nom_var}"}, $mode, $iv); // ICI LA LIGNE EN ERREUR
       $_SESSION["${nom_var}"] = base64_encode($_SESSION["${nom_var}"]);
   }
   else
   {
       $_SESSION["${nom_var}"] = '';
   }
}

J'ai bien essayer de changer la cle et l'IV pour le cryptage mais rien à faire...

Je tient à préciser que j'utilise mcrypt_encrypt() sur ces même variables pour sauver en db sur ce même hebergeur et que tout fonctionne à merveille. C'est juste quand je crypt pour passage en session qu'il y a ce problème

Si quelqu'un a une idée
Merci d'avance

Bonjour,

Tu dois d'abord calculer la taille de ton vecteur d'initialisation IV pour le couple algorithme/mode que tu as choisi.

$iv_size  = mcrypt_get_iv_size($algo, $mode);

Ensuite tu peux créer un IV de ton choix ou en construire un de manière aléatoire.

// de ton choix:
$iv = substr('monIVqueJeChoisisAuHasard', 0, $iv_size);

// création d'un IV aléatoire de la bonne longueur
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);

Une fois que tu as calculé la longueur max de l'IV pour un algo/mode donné, cette longueur reste fixe tant que tu ne change pas d'alog/mode. Tu n'es donc pas obligé de la recalculer à chaque fois.

Idem pour la clé d'encryptage, elle doit avoir la bonne longueur pour l'algorithme que tu as choisi.

Ceci étant dit, il ne s'agit que de warnings qui ne devraient pas empêcher le cryptage. Mais c'est plus propre de le faire correctement dès le départ.

Pour plus de détails:
http://www.phpfrance.com/tutoriaux/inde ... rypt-ripat

Merci Ripat

je voulai savoir autre chose avant de commencer...

Si j'utilise un vecteur aléatoire pour crypter, comment vais je pouvoir décrypter le contenu?

En est il de même pour la clé?

merci d'avance;)

La clé et l'IV doivent être les mêmes pour le cryptage et le décryptage.

L'idée est donc de les construire une fois pour toute. Les calculs de longueurs mcrypt_module_get_algo_key_size() et mcrypt_get_iv_size() ne doivent donc se faire qu'une seule fois.

Tu les stockes dans un endroit sécurisé de ton serveur (éventuellement cryptées avec d'autres IV-clé que tu cryptes avec d'autres que tu... bon, j'arrête de plaisanter)



Ceci dit, si un hacker mal intentionné accède à tes fichiers de sessions, il y a de fortes chances qu'il touve aussi ton script de cryptage et tes clés. Il sera juste (un peu) retardé.

j'ai fait un test sur mon hebergeur grace à ton script gracieusement proposé et il m'indique pour mon couple algo/mode, une taille de clé et de vecteur de 32 bit pour les deux...

1) peut on mettre n'importe quel caractères dans la clé et l'iv (32 caractère dans mon cas)?

2) j'ai bien une clé et un iv 32bit pour mon problème... J'ai de bon résultat en db mais pour ce qui est des sessions, j'ai dut changé de clé et d'iv car cela buggais avec certain caractère spéciaux dans ces clé et iv
lorsque je décryptais via les même iv et clé, cela affichai n'importe quoi dans mes champs de formulaire (plein de caractère bizzard)

Pour mon problème, les warning ne genne pas plus que ça mais si je quitte le formulaire et que je revient dessus, mes variable de session devienne bizzard elles aussi. Lorsqu'ensuite je fait actualiser, ces variables change à chaque click sur le bouton et devienne de plus en plus courte jusqu'a n'afficher plus rien


donc si quelqu'un voit une raison à cette bizzarerie:-k
merci d'avance

j'ai fait un test sur mon hebergeur grace à ton script gracieusement proposé et il m'indique pour mon couple algo/mode, une taille de clé et de vecteur de 32 bit pour les deux...

Hum... je crois deviner de quel algo il s'agit. C'est du bon, c'est du belge!

1) peut on mettre n'importe quel caractères dans la clé et l'iv (32 caractère dans mon cas)?

Oui.

2) j'ai bien une clé et un iv 32bit pour mon problème... J'ai de bon résultat en db mais pour ce qui est des sessions, j'ai dut changé de clé et d'iv car cela buggais avec certain caractère spéciaux dans ces clé et iv
lorsque je décryptais via les même iv et clé, cela affichai n'importe quoi dans mes champs de formulaire (plein de caractère bizzard)

Si les clés et IV sont strictement les mêmes au décryptage, c'est impossible. Si les clés et IV sont construits à partir de données d'un formulaire, attention au jeux de caractères de celui-ci. Vérifie, dans ton script, si ces clés-IV sont strictement identiques au cryptage et décryptage.

ok j'ai déja résolut un point grace à toi
Il manquait un caractère à mon vecteur...j'avais pourtant recompté

mais mon problème est que lorsque je fait un retour sur mon formulaire, mes variables de session sont bien mise dans les champs du formulaire.
Si par contre je fait actualiser, elle devienne n'importe quoi

je decrypt pourtant en tout debut de formulaire et je recrypt a chaque fois que c'est nessessaire avant de réenregistrer en session

je sait plus ou donner de la tête

C'est un problème de manipulation de variables dans ton script. Mets des echo et print_r($_SESSION) aux bons endroits et tu trouveras.

Ceci dit, je pense que tu te fatigues, ou tout du moins te compliques la vie pour pas grand chose. Si tu veux protéger tes fichiers de sessions contre un visiteur non invité et malveillant, si celui-ci y a accès, ton serveur est mort de toute façon. Sessions cryptées ou pas.

le truc c'est que tout fonctionne lors de mes test en local via easyPHP.
C'est donc qu'il n'y a pas de soucis dans mon script

par contre sur le server de l'hebergeur, c'est là qu'apparait le problème

peut être cela vient il de la config de php pour les sessions chez l'hébergeur?

PS: je fait cela pour lutter contre le vole de session
(surtout dans le cas ou le hacker va chercher à voler un cookie de session d'un visiteur plutot que de prendre le risque de pirater le server de l'hébergeur qui lui est sencé savoir ce proteger...

PS: je fait cela pour lutter contre le vole de session
(surtout dans le cas ou le hacker va chercher à voler un cookie de session d'un visiteur plutot que de prendre le risque de pirater le server de l'hébergeur qui lui est sencé savoir ce proteger...

Dans ce cas le cryptage est inutile car si le hacker vole le cookie de session, il aura accès à son fichier de session. Que celui-ci soit crypté ou pas. Sauf si la clé de cryptage est une donnée introduite par l'utilisateur autorisé et connue de lui seul. Mais je ne le vois pas l'introduire à chaque page...

très bien, je vais faire autrement pour sécuriser mes sessions.

En limitant la durée des variable de session via un timing par exemple...

en tout cas merci pour ton aide précieuse

Pour éviter le vol de cookie de session tu peux déjà désactiver le session.use_trans_sid et mettre le session.use_only_cookies en "on"

Tu éviteras ainsi les attaques du type "hot link".

Par ailleurs protège-toi des attaques XSS (Cross Site Scripting) en transformant l'affichage des inputs des utilisateurs en entités html. Tu évitera ainsi l'injection de <script>java.script.malveillant</script>.

Un peu de lecture:
http://phpsecurity.org/ch04.pdf

Mais il y a tellement à dire encore en matière de sécurité...

Merci pour les conseils