cookie crypté

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : cookie crypté

par dunbar » 07 août 2008, 00:47

j'ai reussit a echapper de justesse une attaque par la session j'ai donc tout virer je preferent les cookie dont je verifie le contenue qui ne doit conetenir que des chiffre ou je bloque le script.
il a reussit a en tirer des password ma cle de cryptage md5 et plein d'autre info.
voila pourquoi je ne veux plus de session le risque est trop grand par rapport a ce quel apporte.
Tu peu ajouter une somme de contrôle à la valeur de ton cookies, prend la valeur que tu souhaite stocker dans le cookie, et ajoute un préfixe et/ou suffixe et place la valeur de contrôle a la fin de celui-ci.
A partir de là il est très facile de savoir ci le cookie a été modifier.
Exemple :
Le cookie envoyé
<?php
$cookies = array('donnee1'    => 'valeur1',
                 'donnee2'    => 'valeur2');

$cookies['sdc'] = md5("prefixe".join("|", $cookies). "suffixe"); //création de la somme de controle
foreach($cookies as $donnee => $valeur) {
	setcookie($donnee, $valeur);
	}
?> 
Affichera ceci :
Array
(
[donnee1] => valeur1
[donnee2] => valeur2
[sdc] => 7ac729c521c443e2b58e1246835fa1ea
)
Pour vérifier ton cookie :
<?php
$sdc_lue = $cookies['sdc']; //récupération de la somme de controle
unset($cookies['sdc']);
$sdc_cal = md5("prefixe".join('|', $cookies) ."suffixe"); //Calcul de la somme du cookie

if ($sdc_cal != $sdc_lue) { //vérification des deux somme

//les cookies ont été modifier
	$cookies = array();
	}
?>
Affichera ceci :
7ac729c521c443e2b58e1246835fa1ea
La moindre modification du cookies modifiera cette signature donc il est assez simple de le vérifier :wink:

par hakazizi » 04 août 2008, 17:23

si j'ai bien compris zeus t'inquiete.
je prend les devant pour le ou les prochains qui viendront...
celui la je l'est vue venir.
mais qui me dit que d'autres ne viendront pas apres et peut-etre je les verrais meme pas venir et quand je les verrais il sera peut-etre trop tard pour intervenir.

par zeus » 04 août 2008, 14:22

Je crois que tu n'as toujours pas compris le fond de l'histoire ...

Alors, 1èrement, à la vue de ce que j'ai lu, tu as eu quelques tentatives de SQL injections ... c'est possible que ça ait été un bot qui est passé quelques jours, qui n'a rien trouvé et qui est reparti. Donc, ne part pas tout de suite sur le fait qu'un méchant kikoulol essaye 14h par jour de pirater ton site ;)

Ensuite, ton soucis, c'est un problème de SQL injection, pas de session. Il faut donc que tu blindes la vérification des données, mais pas leur support ...

Mettre des données sur un cookie, c'est une faille de sécurité dans le pire des cas, et dans ton cas, construire un 38 tonnnes pour rammener tes courses à la maison.

Donc, mon conseil, c'est de prendre une heure ou deux, de te poser et de réflechir calmement à ce qui ne convient pas et de chercher plusieurs solutions et pas uniquement la 1ère qui te passe par la tête ;)

par hakazizi » 04 août 2008, 14:15

si il a tester les injetctions sql rien ne me dit qu'il ne va pas tester autre chose donc je verrouille toutes les entrées possible.
l'utilisateur de base ne modifira pas son cookie mais le comique de service oui...

par Berzemus » 04 août 2008, 14:09

un cookie pour éviter les attaques par cookie ?

De ce qu'il me semble comprendre de ton autre post, c'est la requête vers ta bd qui est la cible. Je me concentrerais la dessus.

par hakazizi » 04 août 2008, 12:26

cela evite les attaques par cookie j'y est penser aussi je verrouille tous

par zeus » 04 août 2008, 11:56

Alors, plusieurs réponses :
1/ un fichier de session côté serveur contient plus que le sessid. C'est le cookie client qui ne contient que le sessid.
2/ La taille maximale des sessions peut être configurée directement via la conf PHP (donc possible avec un code PHP ou un .htaccess)

Sinon, je ne comprend pas pourquoi tu as absolument besoin d'un cookie pour vérifier qu'il n'y ai que des chiffres :-k
Je ne sais pas si je suis encore en vacances où si je suis plus simplement idiot, mais j'ai pas compris ce que changerais le cookie par rapport à la session. :?

par hakazizi » 04 août 2008, 11:48

j'ai deja apporter ne reponse ici

http://www.phpfrance.com/forums/voir_sujet-242037.php
merci a tous

par zeus » 04 août 2008, 10:16

Est-ce que tu sais que le principe des sessions est de placer un cookie sur le poste client qui contient l'identifiant de la session.
Les données de la session sont quand a elles stockées sur le serveur. Le serveur est généralement sécurisé et donc ces informations sont inaccessible sans authorisation.

Je n'ai pas tout compris dans ton système, mais tu va réinventer le principe des sessions, et donc créer un truc moins performant (une surchouche est plus lente qu'un fonctionnement intégré au coeur), moins sécurisé et moins bien pensé (par exemple, le système de portage du sessid dans l'url si refus du cookie)

Franchement, décrit nous l'attaque que tu as subis, qu'est-ce qui t'a permis de la remarquer et qu'est-ce que te fait penser que ton système est plus sécurisé ?

PS : d'expérience, je sais que quand on essaye de redévelopper les système de sécurité de PHP, c'est qu'on part dans la mauvaise direction ;)

par _activmik » 04 août 2008, 09:43

Si la personne qui t'en veut t'as attaqué par les sessions, ca va donner quoi avec les cookies ?

Enfin, c'est ton choix, et désolé je vois pas comment faire, mais je vais suivre ce fil de discussion avec attention 8-)

par hakazizi » 03 août 2008, 23:10

j'ai reussit a echapper de justesse une attaque par la session j'ai donc tout virer je preferent les cookie dont je verifie le contenue qui ne doit conetenir que des chiffre ou je bloque le script.
il a reussit a en tirer des password ma cle de cryptage md5 et plein d'autre info.
voila pourquoi je ne veux plus de session le risque est trop grand par rapport a ce quel apporte.

par Berzemus » 03 août 2008, 22:41

Miam, c'est bon les cookies..

:love5:

et pour être utile, les sessions, c'est mieux que les cookies, et ça marche même sans. Tu n'as pas a t'occuper des soi-disants "degrés" d'acceptation des cookies. Soit on accepte, soit pas. Taille max dans les 4096 caractères, maximum 20 par domaine, et max 400 en tout. C'est le minimum conseille, et donc le max pour IE6.

par _activmik » 03 août 2008, 21:31

Mais pourquoi ne pas passer par des $_SESSION[''] ?!

par hakazizi » 03 août 2008, 12:32

mon probleme est donc insoluble?
si il y a plusieurs niveau de blocage des cokkies, c'est bien que l'on peut atteindre l'avant dernier, le dernier etant le blocage total.
merci.

par hakazizi » 01 août 2008, 14:31

il y a differend niveaux de confidentialite si il bloque tous les cookie il est bien evident que la je ne peux rien ils ne pourront jamais se connecter mais d'un niveau inferieur accepter les cookie qui ont une strategie ou quelquelque chose comme sa.
et il est assez rare que quelq'un refuse tous les cookies