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

[méphistopheles]

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]

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]

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]

....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 :

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]

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]

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]

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

Code :

 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]

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 :

heu, en quoi consiste ce risque ?

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

Code :

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]

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 :

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

c'est ca :

Code :

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 :

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]

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 :

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

Merci.

[viviboss]

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]

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]

....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]

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

ULTIME

[méphistopheles]

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]

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]

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]

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.