[Cookies] Se fabriquer un cookie , l'enfoncer dans son navigateur et pirater mon site

[psychoBob]

Bonjour,

Les nouvelles aventures de PsychoBob au pays des cookies de session:

J'utilise une condition pour l'affichage de certaines pages. Il s'agit de tester si le cookie de session existe, sinon le header renvoit sur la page d'identification.

Code :

1
2
3
4
5
if(!isset( $_COOKIE[ session_name() ] ) )
{
 die(header('Location:dentification.php'));
;}

Bon, mais ne vaut-il pas mieux faire cela :

Code :

1
2
3
4
if(!isset($_SESSION['pseudoSession']))
{
 die(header('Location:identification.php'));
;}

Parce qu'à priori le gars va pas pouvoir se créer une variable de session sur le serveur sans être connecté. Par contre il peut peut-être se fabriquer un petit cookie de session, l'insérer dans son navigateur et faire croire à mon site qu'il est connecté.
J'ai tout compris ?

[Swoög]

oui, tout compris

en général : ne jamais faire reposer un point de sécurité d'un site sur cookie.

Ils peuvent être forgés (faille de sécurité)
Ils peuvent être désactivée (faille de disfonctionnement)

[psychoBob]

Donc la première solution est une passoire alors que la seconde est fiable ?
Peut-on passer outre la seconde, du reste ?
Et est-ce la peine de faire plusieurs fois dans la page des test d'existences de variable de session, dès lors qu'un premier test à pour instruction de déclencher le header s'il retourne false ?

J'ai encore du mal à piger le mécanisme là. Mettons que le gars est chez lui il veut afficher une page à accès réservé sans avoir de compte.
Il ne peut pas forcer mes formulaires, il ne lui reste qu'à forcer la condition d'existence des sessions, fait par mes scripts ci-dessus.
Comment il fait ?
De même, si je fais :
if(!isset( $_COOKIE[ session_name() ] ) )
{session_start();}

Puisque le gars peut se fabriquer un faux cookie, il peut aussi très bien démarrer une session sans être connecté. Et là ? Qu'estce qu'il peut faire ? A priori la session ne comportera pas de variables puisquelles sont créés en cas d'identification seulement.

ça fait un max de questions mais elles m'intéressent toute autant.Si quelqu'un a le courage de les traiter une par une, ça sera génial, merci.

[Swoög]

le seul moyen de contourner le second test est le vol de session (ou le piratage du serveur)

si tu es sûr à 100% que ta variable de session existe (exemple, arrêt prématuré du script en cas de non-existence) alors le test de blocage suffit (celui qui arrette le script) à condition qu'il soit fait avant les autres accès à la variable bien sûr

[psychoBob]

En tout, je fais cela en haut de mes pages, dîtes-moi si vous-y voyez une faille :

Code :

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
 
<?php
//test si le cookie de session a été créé lors de l'authentification
if( isset( $_COOKIE[ session_name() ] ) )
{
//démarrage de la session
    session_start();
   //verification du temps d'activité ou d'inactivité
if(time()-$_SESSION['dernier_acces']>1200) 
{
//si plus de 1200 secondes d'inactivité : on détruit cookie et session
setcookie(session_name(), '', 1 ); // on détruit le cookie
//on détruit la session
$_SESSION = array();
session_destroy();
}
//si le délais n'est pas dépassé, on réinitialise la variable de session 
au temps actuel.
else
{
$_SESSION['dernier_acces'] = time();
}
}//fin du test d'existence de cookie de session
 
//si la variable pseudoSession initialisée dans le script d'identificiation.php
 n'est pas présente, alors on renvoit à la page identification.php
if(!isset($_SESSION['pseudoSession']))
{
 die(header('Location: identification.php'));
;}
?>

Qu'est ce que vous en pensez ? Du point de vue de la sécurité j'entend, parce que ça fonctionne bien sinon (à l'exception d'opéra qui connecte et déconnecte sans arrêt mais bon je verrais ça plus tard.

[Maxoo]

pourquoi tu te sers de cookies ?

les sessions suffisent largement pour ce que tu veux faire, ton test sur les cookies est comme si tu mettais if(1), parce que pour moi les cookies sont des supers passoires.

Donc voila.

[psychoBob]

Je me sers des cookies parce que je veux que les sessions passent par les cookies et pas dans l'url, masquées ou non.

[Maxoo]

une session, si je ne m'abuse, c'est :
toutes les infos stockées sur le serveur.
et un ids stocké sur ton disque.

donc je vois pas trop de quoi tu parles.

[psychoBob]

Je parle de l'id de session, parce qu'un id de session en cookie ça se vole plus difficilement qu'un id de session dans l'url.

[Maxoo]

dans ce cas, utilise les session, et fait un IDS2 de ton cru que tu balades dans l'url avec les GET.

[psychoBob]

Comment ça utilise les sessions ? J'utilise les sessions j'ai des variables de sessions simplement c'est l'id de session qui est stocké chez le client dans un cookie.
Y'a une fonction pour ça normalement session_use_cookie() ou un truc comme ça mais apparemment chez ovh on a du mal avec ce truc (cf le post de Titoumimi).

Je sais pas ce que c'est qu'un IDS2 (id de session?) et je veux pas qu'il y ait quoi que ce soit dans mon url, c'est d'ailleurs la première raison pour laquelle je force les sessions par cookies parce que sinon les moteurs vont morfler avec des urls désastreuses. d'ailleurs c'est mon site qui va morfler, pas les moteurs. Et accessoirement c'est plus sur par cookie.

[Djakisback]

Je parle de l'id de session, parce qu'un id de session en cookie ça se vole plus difficilement qu'un id de session dans l'url.

Quand les paquets sont envoyés en HTTP sur le réseau, il me semble (mais pas sûr ^^) que l'un ou l'autre des deux cas ne change absolument rien. L'info est de toute façon présente dans les paquets.
Un moyen de limiter un peu le vol de session est de stocker l'ip et l'id de session du client dans une BDD et de ne délivrer les pages qu'après vérification sur chaque page. Mais bon, il suffit que deux personnes soit sous le même proxy et si l'une vole l'id de session de l'autre, elle pourra se connecter vu les 2 clients auront la même ip.

[berceker united]

Plutot que de gerer le session via php tu peux gérer les session via une base de donnée. Ainsi c'est toi qui émule le tous et tu es sur qu'elle ne peut passer dans l'url puisque c'est toi qui le gère.

[psychoBob]

Quand les paquets sont envoyés en HTTP sur le réseau, il me semble (mais pas sûr ^^) que l'un ou l'autre des deux cas ne change absolument rien. L'info est de toute façon présente dans les paquets.

Je vois pas bien comment ça fonctionne mais celon tout ce que j'ai lu les sessions se vole bcp plus difficilement quand l'id passe en cookie plutot que dans l'url. Il faut alors utiliser un script pour récupérer le cookie chez le client, script qui ne fonctionne plus si on filtre les entrées de formulaire via htmlspecialchars.
Ou alors il faut aller sur le pc du client récupérer physiquement le cookie.
Je répète ce que j'ai compris de ce que j'ai lu.


Je vois mal comment faire passer par une base de donnée en plus c'est beaucoup plus lourd quand même. Mais admettons, il va bien falloir le faire passer de page en page le faux id de session. Et là comment faire sans le faire passer l'url ou en cookie ?