[Sécurité] A t'on besoin de prendre des précautions pour les variables de session ?

**méphistopheles** · 19/12/2006, 21h53

Bonjour.

Je me demandais s'il étais possible pour un utilisateur de renvoyer (mais est-ce lui qui les renvoie ?) des variables de sessions erronées, c'est à dire qu'il serais par exemple en mesure d'entrer des codes mysql (par exemple) dans une des lignes/cellules de la variable ?
Je sait que c'est le cas pour les variables GET POST et pour les cookies, mais là, je me tâte (pas besoin d'utiliser une goudronneuse sur un sol en marbre...).

bref, si vous avez une idée sur la question, merci de m'alléger (ou non) de certaines lignes de code.

Au fait, question subsidiaire: quand je filtre des variables de type $_POST, j'applique le htmlentities(xxxx, ENT_QUOTES), mais je fait auparavant des comparaisons (if ou Switch) non protégées. est-ce que cela représente une faille ?(comment ça je suis parano

)

Merci

**juJuv51** · 19/12/2006, 22h05

Normalement non, étant donnée que les variables de sessions sont intouchable.
(enfin je pense, mais j'ai rien vue de tel sur internet et les sites qui traite de sécurité et de faille d'exploitation)

phpSecure.info je pense que ça doit en parlé si ça existe

**Eusebius** · 19/12/2006, 22h12

Bonjour
Les variables de session restent sur le serveur. Le seul risque qu'il y ait est au niveau de l'identifiant de session (tu pourras faire une recherche sur les attaques de type vol de session ou fixation de session si tu veux plus de détails).

**viviboss** · 19/12/2006, 22h20

....Et encore, car l'identifiant de session reste sur le même domaine (pas de fuites vers l'extérieur....)

Par exemple, si tu met en favoris une page munis d'un identifiant de session, l'identifiant est automatiquement retiré par PHP. Ainsi, lorsque on refait appel au favoris, il faut reprendre obligatoirement une session.

Il y a par contre des risques si tu fais des test dans tes codes, du style :

Code :

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

1
2
3
4
5
 
if($_SESSION['login']=='ok'){
header("Location :page.php?login=ok");
exit();
}

Mais dans ce style d'utilisation, on est bien d'accord que la session est totalement inutile.....

Bref, y a pas trop de risque avec les sessions, mais n'hésite pas à parcourire toute les pages du manuel PHP (voir ma signature) à ce sujet, il est extremement explicite, et donne des exemples de sécurisation de session.

(Au lieu de parler de "sécurisation", je dirais plutot des habitudes de programmations.....)

**Eusebius** · 19/12/2006, 22h27

Envoyé par viviboss

....Et encore, car l'identifiant de session reste sur le même domaine (pas de fuites vers l'extérieur....)

Je répète mon conseil alors : si ça t'intéresse renseigne-toi sur les attaques de type "vol de session" ou "fixation de session". L'ID de session transite dans les requêtes HTTP, il peut être intercepté, modifié, il est sensible à un man in the middle...
Mais bon c'est sûr c'est pas du même niveau que de bidouiller une requête GET.

**viviboss** · 19/12/2006, 22h31

Envoyé par Eusebius

un man in the middle...

....Ou un "monkey in the middle", pour reprendre la terminologie d'un célèbre outil sous Linux, pour "tester" les failles réseaux !!!!

**méphistopheles** · 19/12/2006, 22h32

j'ai regardé là dessus: est il obligatoire de faire ceci, ouest-ce par défaut:

Code :

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

 session.use_trans_sid=0

?

esuite, j'ai bien trouvé cela, mais je crois que là, la barre est un peu (et inutilement haute pour moi).

sinon, qu'en est-il pour ma deuxième question ?

merci.

**méphistopheles** · 19/12/2006, 22h38

désolé pour le décalage, je met du temps à poster.

Envoyé par viviboss

Il y a par contre des risques si tu fais des test dans tes codes, du style :

Code :

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

1
2
3
4
5
 
if($_SESSION['login']=='ok'){
header("Location :page.php?login=ok");
exit();
}

heu, en quoi consiste ce risque ?

car je fait bien des requetes de ce type avec des $_POST:

Code :

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

1
2
3
4
5
if (isset($_POST['Login'])){
   if ($_POST['Login']==$quelquechose) {
      //je fait ce que je veut;
}
}

cela comporte donc un risque ?

merci.

**viviboss** · 19/12/2006, 22h50

Et bien, comme tu l'as dit plus haut, il est plus facile de trouver des failles dans des comportements GET et POST.

Dans le cas quze je t'ai présenté, je vérifie le login avec une session, mais je transmet un "OK" en GET.....

Donc je peu shunter la session : il suffit que je tappe dans mon navigateur directement la variable GET (on a header :page.php?login=OK, donc il suffit que je tappe dans mon navigateur cette adresse pour passer à travers....)

A mon avis, si tu utilise des sessions pour un "login", il faut que tu reste en session jusqu'à la fin, et pas que tu change de méthodes en plein milieu.... (ca demande peut être un peu plus de temps à poffiner tes scripts, mais au moins tu gagne en sécurité.)

Quand tu test ton login, s'il est bon, tu peux créé une nouvelle varialbe de session (exemple : $_SESSION['login']=1), et tant que cette variable n'hexiste pas ou n'est pas à 1, bas le client va pas plus loin.....Donc tu force tes clients à passer par ta gestion de login, et vu qu'ils ne peuvent pas voir à quoi ressemble tes variables de session, ils ne peuvent pas le shunter !!!!

une bonne méthode à ca :

Code :

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

1
2
3
4
5
 
if($_SESSION['login']=='ok'){
header("Location :page.php?login=ok");
exit();
}

c'est ca :

Code :

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

1
2
3
4
5
 
if($_SESSION['login']=='ok'){
header("Location :page.php".strip_tags(SID));
exit();
}

là, je gère le passage de session. Et dans page.php :

Code :

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

1
2
3
4
5
6
7
8
 
if(isset($_SESSION['login']) && $_SESSION['login']=="ok"){
//na bla bla bla bla
}else{
//si la session n'est pas active
header("location :index.php");
exit();
}

**méphistopheles** · 19/12/2006, 23h03

merci, en fait, là, je n'avais pas compris d'ou pouvais venir la faille de ton exemple.

en fait, dans ma deuxième question, je me demandais juste s'il étais possible d'avoir son script corrompu par une variable _GET ou _POST qui contiendrais (par exemple) des instruction php, alors que j'utilise un htmlentities dés que je manipule la variable, mais que je ne prend pas cette précaution dans les comparaiseons, c'est à dire: la pfaille pourrais-elle venir de la compparaison même lors, par exemple de la récupération d'un formulaire avec:

Code :

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

if (isset($_POST['Login']))//cette seule ligne peut-elle être une faille ?

Merci.

**viviboss** · 19/12/2006, 23h13

Bien sur qu'elle peut avoir une faille.

Il faut faire un maximum de controle sur tes variables, c'est clair : avant ton HTMLentites, tu devrai faire un TRIM, pourquoi pas vérifier la longueur de ce que l'utilisateur renvoie (tu pourrais forcer un maximum de 10 lettres pour le login, par exemple....) vérifier s'il y a des chiffres dans le login, des quotes, des points, ou tout autre caractères innatendu (?;/!*$\|, etc....).

Dans ton formulaire, n'oublie pas l'attribut "maxlenght", que beaucoup de gens oublient, dans les text.....(si tu es dans un site internet, cela évite les spammeurs d'utiliser ton formulaire pour mettre autre chose que les infos demandés....)

**méphistopheles** · 19/12/2006, 23h33

aie, il n'y as pas que les quotes... alourdissements de code en conséquence... ça me fatigue déjà... surtout si je dois le faire AVANT les comparaisons (pas de faille dans le isset au moins, sinon, je me suicide (comment ça ça vous arrange

?)) heu... il existe une pas une fonction qui fait tout ça (d'accord, ça c'est de la flemme, je pourrais la faire... sauf que passer la valeur en paramètre ne risquerais -t'il pas d'être une faille ...?)

je sent que je sombre dans la paranoïa la plus totale...

(qui à dis schizophrénie ?

)

bon, je part en flood, j'arrête le massacre et je vais me coucher.

bonne nuit.

**viviboss** · 19/12/2006, 23h45

....Et bien disons que aucun système n'est parfait.

Pour l'injection SQL, il faut un accès aux quotes et symboles de comparaisons (<>=) donc tu limite ca avec HTMLEntities, mais si un gars arrive à trouver une parade (je sais pas laquelle....

) il vaut mieux que d'origine, dans tes champs login et password, tu vire d'office TOUT les caractères spéciaux (tu ne laisse que les lettres et les chiffres....) et tu met un maxlenght à tes formulaires.

Là, tu seras assez blindé.....

Il me semble qu'il y a une fonction php qui permet de n'utiliser qu'une tranche de caractères ASCII....Cela t'évitera peut être d'avoir à créer une expression régulière assez longue et lourde....

Mais ce n'est pas ca qui chargera tes scripts !!!!! (disons pas jusqu'à laisser une personne boire son café ....

)

Bonne chance !!!! Mais sache qu'un abut de sécurité risque d'être contraignant pour tes utilisateurs.....(il faut que la sécurité soit en proportion des informations à protéger !!!!)

Sinon : autre solution, tu ne met pas en ligne !!!!

**juJuv51** · 19/12/2006, 23h49

Sinon : autre solution, tu ne met pas en ligne !!!!

ULTIME

**méphistopheles** · 20/12/2006, 19h15

Envoyé par viviboss

Il me semble qu'il y a une fonction php qui permet de n'utiliser qu'une tranche de caractères ASCII....Cela t'évitera peut être d'avoir à créer une expression régulière assez longue et lourde...

un filtre de type [alphanum], ça doit pas être trop compliqué.

par contre, la la faille vient bien de l'exploitation des données, non des vérificataions effectuées dessus: (tant que je ne cherche pas à sortir la chose de la variable, il n'y as pas de problèmes !)
donc mes comparaison ne souffrent pas de ce défaut (si je ne met pas un '=' au lieu d'un '=='

).

bon, ben c'est moins grave que je le pensait.

pour les sessions, j'ai quelques sessions modos à sécuriser, mais je pense qu'il ne sera pas abusif de leur demander de s'identifier à chaque fois (pas de risques avec les cookies, ce n'est pas nésséçaire,les conextions ne seront pas régulières.).

salut

**méphistopheles** · 21/12/2006, 21h59

Ha! une nouvelle question :

J'utilise des pages que je charge dans des includes à partir d'une page principale qui vérifie les paramètres de conection session. (au fait, combien de temps dure une session ?). à partir de ces pages secondaire, je me contente de vérifier le contenu d'une variable, mais ceci ne représente-il pas une faille (est il possible d'appellel la page en lui envoyant une variable globale (!= superglobale) qui lui ferait croire à la conection ?

merci.

**viviboss** · 22/12/2006, 00h14

Une session dure le temps que la personne est connecté et que la session n'est pas détruite explicitement.

Elle est aussi ouverte tant que le navigateur est ouvert (si une personne passe à une autre page en plein milieu de sa session, et revien dessus après, la session sera toujours active......), et dès que le navigateur est fermé, la session l'est aussi.

Mais tu peux régler tes sessions soit dans le PHP.ini, soit avec un ini_set (notamment souver les variables en bdd, créer son propre SID, etc....)

Quant à ton autre question, il semblerait que le gros risque lié aux includes, c'est plutot quand tu inclue une variable, pas un fichier complet......

Perso, je fais pareil que toi : bloc conditionnel et si oui alors include....

Mais je te conseillerais quand même de séparer ta page de login du contenu qu'il y a derrière.....(tu ne fais pas d'include dans ta page de login, tu redirige explicitement vers une page, qui elle peut avoir tout ce que tu veux comme include....)

Comme ca, tu limites les entrées dans ton contenu protégé à une seule : ta page de login......

**méphistopheles** · 22/12/2006, 15h28

heu non, à vrai dire, la vérification ne sefait pas avant l'include, mais dans la page incluse. La vérification se fait donc dans la page incluse à propos d'une variable de la page incluante.

sui-je clair ?

merci.

[Sécurité] A t'on besoin de prendre des précautions pour les variables de session ?

Langage PHP

Discussions similaires

Partager

Partager