Protéger un appel de page par la méhode GET

Salut à tous,

Bon le titre est pourri mais je trouvais pas comment dire.

La question : quelle est la meilleure méthode pour protéger un appel de page qui prend des variables dans l'url (get) ?

Un exemple, parceque la encore la formulation est pourrie :)

Je fais une messagerie, j'appelle la boite de reception de cette manière : index.php?action=inbox
Cette messagerie comportera quelques fonctions, comme le tri des messages, ou encore les marques comme lus.
Prenons ce dernier exemple, pour marquer des messages comme lus, j'appelle l'url suivante :
index.php?action=inbox&sa=lu
Et hop mes messages sont marqués comme lus. (traitement sur sa = sous action)

Le problème : un type fait une page toute conne, balance un href tout con vers la meme adresse (index.php?action=inbox&sa=lu)
un mec se balade dessus alors qu'il est loggé sur mon site (les deux en meme temps donc, il se balade sur la page étrangère ET il est loggé sur mon site dans un autre onglet) il clique sur le lien vérolé, ca le balance vers mon site à l'URL qui marque ses messages comme lus et paaaaf ses messages sont marqués comme lus.

Voila le probleme.

Pour une raison x je ne peux pas utiliser l'url rewriting ( ce n'est pas discutable, désolé )

J'ai pensé à passer le sessid (ou n'importe quelle autre clé, que je traite derriere) dans l'url. Mais dans ce cas, il suffit qu'un pti gars un peu malin s'amuse à placer un lien de mon site vers son site (un message qui contient une URL, ou même une image !) et hop il récupère la variable passée en GET via le referer ... Si il comprend un peu comment ca marche, il va pas avoir de mal à émuler une adresse valide avec la bonne clé et à balancer le lien vérolé.

Une solution à ce nouveau problème serait de coder les TOUTES les redirection vers les sites externes depuis mon site (ce que je vais faire de toute facon je pense) de facon à ce que personne ne puisse mettre de lien direct, mais que ca passe toujours par une page de redirection qui se chargerait bien de casser toute tentative de recup de variables. (oui, je vais le faire :) )

Je trouve ca un peu tiré par les cheveux comme méthode.

Est il possible de faire autrement ?

Je suppose qu'on peut dire à Apache (il est souvent sympa et compréhensif, et comme tous les indiens, il se balade en info) de n'accepter le GET que pour des pages appellée par mon site, mais dans ce cas ca briserait completement tous les liens vers d'autres pages que la page d'index du site, et ca, je ne veux pas. Je voudrais juste sécuriser certaines pages, sans bloquer systématiquement les appels en GET depuis l'extérieur.

Actuellement j'utilise un système un peu barbare que je nomme (personnellement) "variables à usage unique" qui consiste à générer une variable aléatoire,  l'utiliser dans un algorithme de cryptage qui permet d'enregistrer une variable connue de moi seul en session, de passer cette variable aléatoire comme clé en GET ou en POST à une page B, puis de repasser cette variable dans ma moulinette de cryptage dans la page B pour aller récupérer la variable en session connuedemoiseul qui a été créee dans la page A et vérifier qu'elle a bien la bonne valeur, puis ensuite de faire un unset dans la page B. De cette facon, seule la page A peut appeller une fois et une seule la page B. Si on veut ré-appeller la page B, on doit obligatoirement repasser par la page A (puisque la variable de session a été supprimée). C'est lourd et moche ...

Existe-t-il une méthode standardisée ? Un truc que tout le monde sait sauf moi ?

J'ai beau chercher sur internet, je ne trouve rien. Les mots clés sont pas évidents a trouver (url get sessid protect ... ) je tombe quasiment toujours sur des messages expliquant comment passer le PHPSESSID en cookie plutot qu'en GET -_-

Merci de m'avoir lu jusqu'au bout,

Bon dimanche !

ZeGuizmo

Salut,

Tu peux vérifier le référant :

$_SERVER['HTTP_REFERER']

http://www.php.net/manual/fr/reserved.variables.php#reserved.variables.server

Salut,
Merci pour la réponse rapide, mais ce genre d'info n'est pas fiable, à moins que je ne me trompe.
Le code ci dessous permet de passer tres facilement outre le "referer check", sans parler des plugins "caméléons" pour firefox qui permettent de choisir systématiquement toutes les entetes que l'on veut faire passer ...

<?php

$host = "www.monsite.com"; 

$file = "index.php";


$headers = array( 'http' => array(

    	'method' => 'GET',
	'header'=> 'accept-language: fr'."\r\n" .
	'Host: '.$host."\r\n" .
        'Referer: http://'.$host."\r\n" . //on place le referer qu'on veut placer
	//etc etc ..
    )

);

$context = stream_context_create($headers);
$fp = fopen("http://" . $host . "/" . $file, 'r', false, $context);
fpassthru($fp);
fclose($fp);
?>

De plus, dans le lien que tu donnes, on peut lire :

"Certains navigateurs permettent même de modifier la valeur de HTTP_REFERER, sous forme de fonctionnalité. En bref, ce n'est pas une valeur de confiance."

Merci quand même ^^

Une solution pour sécuriser la chose ?

ZeGuizmo

Alors t'as aucun moyen de t'assurer que la personne n'a pas suivi un lien extérieur.
Mais là, c'est limite paranoïa, hein ;)
Rien de bien grave...

Ou alors, si moyen il y a, je suis curieux de le connaitre...

Hello,

ton exemple est vraiment tiré par les cheveux. Il n'y a quasiment aucune chance que cela arrive. Mais si ça te fait peur, explique moi un truc : pourquoi tu utilises le système le plus facilement cassable pour les actions de ton site, à savoit GET ?
Si t'es parano à ce point, tu devrais passer par un autre système. POST par exemple, ce sera toujours un peu plus difficile...
Ou passer le sessid dans ton get en effet. Et ça c'est pas compliqué...un tour sur php.net te dira tout, pas la peine de naviguer des heures sur google.

Salut,

Euh, get, post, ... quelqu'un qui connait la différence et qui veut foutre la merde ne mettra pas plus d'une minute de plus a utiliser cette faille, il n'aura qu'a jeter un coup d'oeil au code (ctrl + u sous firefox) et utiliser post.

Je ne pense pas que ca soit de la paranoia ... Je m'avancerais même à dire que c'est une faille de sécurité énorme pour un site grand public. Je souhaite (pour le fun plus que pour le succés escompté) créer un jeu en php5. Qui dit jeu dit cheat ... tout le monde le reconnaitra. Cheat en php se rapproche de hack. Il ne faut pas sortir de St Cyr pour se rendre compte de ce trou de sécurité et l'utiliser. Il suffirait à un joueur malveillant de créer un lien vers une page vérolée pour exploiter cette faille.
Beaucoup de joueurs seraient susceptibles de cliquer sur un lien du genre "clique ici et tu gagneras 1000 points en une heure" ... et arriveraient sur une page vérolée. L'exemple que je donne n'est certes pas dramatique, mais on pourrait imaginer des ?action=logout ou encore ?action=erasemyaccount ...(même si je ne suis pas idiot au point de faire ce genre de liens sans vérification au préalable, mais l'erreur est humaine :) ) Que ca soit en get ou en post, je voudrais pouvoir utiliser mes scripts en toute sérénité. (sans qu'un script kiddie place un href bien construit dans une page pour foutre en l'air des mois de travail)

On ne peut pas si on est un tantinet sérieux se baser sur le http referer ...

Quand au passage du sessid en get, c'est également très facilement crackable (si je ne recode pas toutes les sorties de mon site vers l'extérieur, ce que je vais faire, mais je peux oublier des cas !). Comme je l'explique dans mon premier message, n'importe quel être vil et malveillant ayant quelques notions de php saura récupérer, lui, le http referer (la majoirité des utilisateurs ne naviguant pas en mode fantome) simplement en placant un lien direct de mon site vers son site, et par conséquant récupèrera le sessid qui trainera dans l'url.

Et, oui, c'est tiré par les cheveux, oui, il n'y a quasiment aucune chance que cela n'arrive, mais il suffit d'une et une seule fois ... La sécurité en php n'est pas à prendre à la légère (à mon avis) nombre de sites web (et particulièrement de jeux) en ont fait les frais.


Personne n'a jamais rencontré ce problème ?

Merci de vos réponses !

PS : je ne souhaite aucunement enflammer le débat hein, j'ai beaucoup de respect pour vous, qui êtes de biens meilleurs codeurs que moi. Je suis juste surpris qu'une faille telle que celle ci ne vous choque pas plus que ca.

ZeGuizmo

Re,

C'est pas une faille à proprement parler : c'est tout au plus une lacune qu'il n'est pas facile de combler.

Recréer une URL n'est malgré tout pas si simple. Laisser trainer un SID dans l'url... Moi, ce qui m'étonne le plus, c'est comment on peut l'y mettre... Pas oublier de l'enlever. Une simple configuration des sessions permet de s'assurer que le SID n'est pas passé dans l'URL (use_trans_sid à off).
A partir de là, pour choper le SID, il faut quand même autre chose que de simples connaissances en HTTP et en PHP : il faut une adresse IP d'un utilisateur, un ver, un sniffeur et tout le tremblement. Ca se met pas en place d'un simple claquement de doigt.

Pour les opérations sensibles, tu peux rajouter une vérification avec mot de passe et captcha.

Et puis le vol de session, s'il reste possible, est quand même franchement rare car difficile.
Pour le limiter, tu peux utiliser SSL.

Maintenant, si tu crains surtout les liens vers ton site qui viennent de l'extérieur, le problème est ta discipline de sécurité. Si un lien permet une action importante juste en ouvrant la page, c'est que ton appli est mal foutue.
La suppression d'un compte, par exemple, ne doit pas se faire avec un simple lien... Même si un utilisateur souhaite pouvoir se désinscrire, il faut valider avant et désactiver le compte dans la base, sans le supprimer. Tu peux aussi mettre un délai avant cette désactivation : 24h sans activité après la demande de suppression.

La sécurité à 100% n'existe pas, c'est une utopie : dès lors qu'on confie certaines données au client, celles-ci peuvent être modifiées.

Dans ton message, je n'ai pas réussi à comprendre ce que tu redoutes le plus : une action imprudente d'un utilisateur valide enregistré et connecté, ou bien une action par une personne non autorisée sur le compte d'une autre (vol de session).
Parce que les deux cas sont différents.

Et ne te méprends pas : c'est le genre de débat qui m'intéresse tout à fait. Mais il est important (pour moi en tout cas) de bien comprendre quel genre de mauvais fonctionnement tu souhaites éviter.

Re,

Oui, tu as raison, ce n'est pas une faille mais une lacune. C'est une faille si une appli terminée permet ce genre "d'intrusion", c'est une lacune si on y réfléchit et qu'on cherche des solutions.

Ma crainte vient des liens extérieurs. Que des utilisateurs mal-intentionnés créent des liens sur une page qu'ils hebergent pointant vers mon site web, et contenant des actions à réaliser. Et qu'un utilisateur lambda, bien intentionné, aille cliquer sur le lien direct et se fasse piéger par l'utilisateur mal intentionné, celui qui a créé la page vérolée. (j'aime bien ce mot ;) ). Je ne crains pas le vol de session car celui ci est reservé à une élite, comme tu le dis, et on peut encore leur compliquer la tache en reservant un sessid à une ip particuliere pendant toute la duree de la session par exemple, on trouve quelques autres astuces sur le net.

Il est évident que les actions sensibles seront protégées, par captcha ou simplement rappel de mot de passe comme tu le mentionnes.

Ma crainte vient plutot des actions banales. Un simple logout (beaucoup de sites se contentent d'un ?action=logout pour délogger l'utilisateur) ne devrait pas être possible en cliquant sur un lien qui ne se situe pas au sein de mon site.

C'est ce contre quoi je veux lutter, en systématisant un processus (et non en agissant au cas par cas, car j'ai peur d'oublier des choses).

Pour le passage du sessid. Mis à part l'URL, je ne connais que le cookie pour passer un sessid (je ne suis pas la science infuse en php, loin de là ... je découvre). Dans ce cas je ne vois pas comment c'est protégé. Le hacker (on va l'appeller comme ca, l'utilisateur qui crée des liens pourris vers mon site :) ) n'a même pas a voler le sessid, il continue de faire un
<a href="http://www.monjeu.com/index.php?action=logout">cliquez ici et vous gagnerez 1000 points</a>
et si l'utilisateur, naviguant sur plusieurs onglets, est connecté a monjeu.com tout en cliquant sur la page pourrie, sera redirigé vers l'action logout en cliquant sur le lien (si cette action vérifie le sessid par cookie, il sera bien présent, et l'action passera).
Si je fais un check par http referer, le hacker n'aura qu'a émuler un referer particulier, celui de monjeu.com.

L'idée en passant le sessid dans l'url (à la main, ce n'est pas la méthode de passage du sessid du site en général) c'est que ca rend le lien dynamique, dans la page de gestion des actions, je n'aurais qu'a faire un check du sessid (qui arrive par plusieurs voies différentes, dont le fameux lien). A ce moment, le simple lien pointant vers ?action=logout ne fonctionnerait pas. Il faudrait que le hacker lui joigne une variable du genre &sessid=le_bon_sessid pour que ce lien passe. (moi derriere je ferais une sorte de if (session_id() != $_GET['sessid']) die(); ici vulgairement codé, c'est un exemple)

La encore il peut sans problemes et sans trop de reflexion surpasser cette méthode ... Il faudra qu'il vérifie les pages dans lesquelles j'utilise cette méthode, pour essayer de glisser une url directe dans la page en question, puisque dans ces pages le sessid serait présent (j'utilise un forum, une messagerie, des pages d'alliances, bref n'importe quel moyen de s'exprimer est une cible potentielle au passage d'une url directe). Des que l'utilisateur piegé clique sur le lien direct placé par le hacker de mon site (www.monjeu.com) vers le site du hacker, ce dernier peut récupérer le sessid via le referer du site puisqu'il aura ciblé la page précise sur laquelle je passe le sessid en get (et il pourra choper l'ip du visiteur imprudent, aussi, donc pas de protections de ce coté). Sauf si j'encode toutes les sorties directes, c'est une méthode que je propose dans le premier post. Il suffirait de faire une fonction qui redirige toute les sorties de mon site vers l'exterieur en écrasant les headers et toutes les données sensibles. C'est tout à fait faisable, juste que je trouvais pas ca tres pratique.

Apparemment il n'existe rien d'officiel la dessus, pas de méthode standart.

Je vais essayer de réfléchir sur mon systeme variable à usage unique pour le généraliser dans ma classe de session, je pense que c'est la seule facon de savoir si une page a bien été appelée par une autre page une et une seule fois.

Merci en tout cas de vous pencher sur le probleme, je ne suis pas tres doué pour formuler clairement les choses, c'est un défaut qui me pénalise souvent ^^

Sur ce, je vais me coucher, la nuit portant conseil, demain j'aurais la solution (optimiste, je le suis)

Bonne nuit à tous !

ZeGuizmo

Salut,

"Pour le passage du sessid. Mis à part l'URL, je ne connais que le cookie pour passer un sessid (je ne suis pas la science infuse en php, loin de là ... je découvre). Dans ce cas je ne vois pas comment c'est protégé. Le hacker (on va l'appeller comme ca, l'utilisateur qui crée des liens pourris vers mon site :) ) n'a même pas a voler le sessid, il continue de faire un
<a href="http://www.monjeu.com/index.php?action=logout">cliquez ici et vous gagnerez 1000 points</a>
et si l'utilisateur, naviguant sur plusieurs onglets, est connecté a monjeu.com tout en cliquant sur la page pourrie, sera redirigé vers l'action logout en cliquant sur le lien (si cette action vérifie le sessid par cookie, il sera bien présent, et l'action passera).
Si je fais un check par http referer, le hacker n'aura qu'a émuler un referer particulier, celui de monjeu.com."

=> Je ne connais aucun site qui s'assure qu'on n'a pas cliqué sur un lien direct vers une page de déconnexion (pour ne prendre que cet exemple). Vraiment aucun.
La seule solution que je connaisse est d'utiliser le referer.
Même si ce n'est pas fiable à 100%, le "hacker" ne peut pas émuler un faux referer, puisque celui-ci est fourni par le navigateur du client.
Dans ton exemple, il faudrait que le hacker pirate le navigateur du membre de ton site pour que celui-ci transmette comme referer ton site et non le sien. C'est encore plus chaud que de voler une session !
Pour n'importe quel site, certaines actions peuvent être réalisées en tapant directement l'url dans la barre d'adresse. Il ne s'agit pas d'une faille de sécurité, ni d'une lacune : c'est le fonctionnement d'internet.



"Des que l'utilisateur piegé clique sur le lien direct placé par le hacker de mon site (www.monjeu.com) vers le site du hacker, ce dernier peut récupérer le sessid via le referer du site puisqu'il aura ciblé la page précise sur laquelle je passe le sessid en get (et il pourra choper l'ip du visiteur imprudent, aussi, donc pas de protections de ce coté)."

=> Lol ! La faille ne vient pas des logiciels ou des protocoles, mais de ton code, si cette situation se produit ! Comment un hacker peut-il placer un lien sur ton site qui redirige vers son site à lui pour récupérer un SID ? C'est une faille de sécurité facile à combler, qui ne devrait même pas exister !

Si use_trans_sid est activé dans la configuration des sessions, les url qui sont concernées par cette réécriture sont UNIQUEMENT les url locales, certainement pas les url vers des liens externes. Si tu permets à ton appli de rajouter le SID à tous les liens quels qu'ils soient sans vérifier auparavent, c'est une effectivement une faille de sécurité, mais dont l'unique responsable, c'est toi, personne ni rien d'autre.
Une tierce personne ne doit pas accéder au SID : c'est relativement simple, le SID est en toute logique connu du serveur, et du client. Personne d'autre. Si le client copie un lien avec son SID n'importe où sur le web, ce n'est pas une faille de sécurité, c'est de l'inconscience (au sens propre du terme) : c'est une erreur de sa part, comme s'il laissait les clés de sa voiture sur le contact avec les portières ouvertes.


"Il suffirait de faire une fonction qui redirige toute les sorties de mon site vers l'exterieur en écrasant les headers et toutes les données sensibles. C'est tout à fait faisable, juste que je trouvais pas ca tres pratique."

=> Là encore, c'est ta manière de développer qu'il faut revoir si tu as besoin de faire une telle fonction (même si je ne comprends pas bien ce qu'elle ferait précisément).
Les données "sensibles" ne doivent effectivement pas figurer dans les liens externes (SID, mot de passe etc). Mais si tu as besoin de faire une fonction qui "écrase" les "headers" (???) et les données sensibles, c'est que par défaut, tu les passes dans l'url et que tu vérifies ensuite qu'il faut les y laisser ou pas. La bonne méthode serait de ne pas les mettre et de vérifier si tu dois les y placer (si c'est un lien qui en a vraiment besoin, comme un lien de déconnexion).


En conclusion pour l'instant, je dirais que vouloir empêcher un utilisateur de saisir manuellement une url dans la barre d'adresse ou de cliquer sur un lien provenant de n'importe où vers ton site, c'est complètement utopique : il faudrait que tous les navigateurs implémentent correctement le referer, ce qui, me semble-t-il n'est pas le cas (hormis le fait que c'est tout à fait possible à changer si on écrit les requêtes http manuellement, ce qui n'est cependant pas donné à tout le monde).

Quant au vol de session, il n'est possible que si :
- l'utilisateur mets un lien avec son SID sur n'importe quel site internet sans faire attention
- l'utilisateur utilise un ordinateur public et ne ferme pas correctement la session en partant
- un hacker intercepte des paquets entre l'utilisateur et ton serveur

Dans les deux premiers cas, cela revient à laisser sa carte bleue avec son code trainer n'importe où.
Dans le troisième, c'est tellement pas facile que c'est pas donné à tout le monde.

Je pense donc que tu te casses beaucoup la tête mais qu'en fait, les risques sont vraiment, vraiment minimes (pour ne pas dire proches du zéro absolu).

Les failles les plus courantes sont les injections de SQL dans les formulaires ou les url. Ca, il faut y faire attention. Les sessions... On peut toujours utiliser SSL pour consolider le bazar, mais y'a pas grand chose d'autre à faire.