Protéger un appel de page par la méhode GETRésolu

Question

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

cs_zeguizmo · Accepted Answer

Le disco de google c'était pour montrer a neige d'hiver que ce qu'il avancait était faux ... Des sites proposent des discos sur simple URL, et même des sacrés pros.

J'ai l'impression d'un dialogue de sourds ... action=logout est une action banale, mais dieu sait quelles actions ils arriveront peut-être à "injecter" si je les sécurise une par une et que j'en oublie une. Et je trouve ca très moche de sécuriser les actions une à une, justement parceque je risque d'en oublier une ... de ne pas penser que telle action serait domageable pour le joueur, alors qu'elle l'est, ca peut arriver ! L'objet de la question était de trouver une méthode généraliste pour sécuriser efficacement l'ensemble des actions, et de vérifier la provenance de l'appel pour chacune d'entre elles. Tout en autorisant certaines d'entre elles (je ne souhaite pas que les utilisateurs ne puissent faire aucun liens vers mon site, simplement en sécuriser un groupe avec une méthode généraliste).

J'ai déjà eu ma réponse en fait, aucune méthode généraliste employée couramment n'est utilisée ... sinon vous auriez certainement déjà été au courant. Je vais donc rester sur mes variables à usage unique, tentant de généraliser ma méthode.

Je suis tout de meme un peu decu de me faire traiter comme un dégénéré (voire meme comme un con) alors que certaines personnes, tout autant pros que vous, bénéficiant elles même d'une grande expérience, sont interessées par le problème et avouent vouloir entendre une solution, c'est que mon problème n'est pas si idiot que ca ... Malheureusement je ne cotoie ces personnes que dans le cadre professionnel et elles n'ont pas de temps a consacrer à mon jeu, projet personnel. C'est pourquoi je m'en étais remis à vous. Je n'ai pas eu l'impression d'avoir été incorrect pour me faire aboyer dessus de la sorte ... Je souhaitais simplement perfectionner mon code en éliminant ce que moi, et d'autres personnes, considèrent comme un problème.

Ce sujet semble clôt. (cela ne sert a rien de redire une 5eme fois les memes choses, ni d'un coté ni de l'autre)

Merci quand même de votre aide, elle m'a appris certaines choses.

ZeGuizmo

neigedhiver · Answer

Salut,

Tu peux vérifier le référant :

$_SERVER['HTTP_REFERER']

http://www.php.net/manual/fr/reserved.variables.php#reserved.variables.server

cs_zeguizmo · Answer

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'."
" .
'Host: '.$host."
" .
        'Referer:

neigedhiver · Answer

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

neigedhiver · Answer

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

malalam · Answer

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.

cs_zeguizmo · Answer

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

neigedhiver · Answer

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.

cs_zeguizmo · Answer

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 
cliquez ici et vous gagnerez 1000 points
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

neigedhiver · Answer

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
cliquez ici et vous gagnerez 1000 points
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.

malalam · Answer

Hello,

un SID est temporaire hein, il ne dure que le temps de la session (24mn d'inactivité, par défaut). Donc même si un utilisateur mets un lien avec son SID courant s ur un autre site, le "hacker" a intérêt à faire vite...
Franchement, je ne vois pas de problème dans tout ce que tu dis. Et ton premier exemple me laisser tjrs rêveur : je suis loggé sur ton site, et en même temps je pose un lien affichant mon inbox sur un autre site, je clique sur ce lien, et je me retrouve dans mon inbox. Et alors ? Tu as peur que tes utilisateurs piratent leurs propres comptes...?
Moi je me mogge sur phpcs, et je mets la page en favoris. Je ferme mon explorateur et je le rouvre et je clique sur mon récent favori : je me retrouve loggé sur phpcs. Argh. Nan sérieux...où est le problème ?

Tu utilises les sessions de façon normale pour ta gestion de compte
Tu checkes bien tes GET pour être certain de ne pas être victime d'un XSS

Si tu fais ces 2 choses, je ne vois pas trop ce que tu risques niveau HTTP.

T'as peur qu'un mec se connecte à distance en attaquant ton site en GET ? Il ne pourra le faire que sur SON compte.
Tu as peur qu'un robot attaque tes url sans cesse et fasse tomber ton site ? Ben ça, ça peut t'arriver avec un bête index.php.
Tu as peur qu'un robot fasse des milliers d'inscriptions à la suite sur ton site ? Un captcha bien foutu sera une bonne parade.

Il n'est pas difficile de bien sécuriser un site. Il est impossible de le sécuriser totalement. 
Je développe avec mon équipe des sites en tant que professionnel depuis un moment déjà...et pour de très grosses boîtes (très très, TRES grosses) : aucun de ces applicatifs web (ouais, des sites et des applicatifs web) n'a jamais été victime d'attaque en règle non contrée. Et ce, en suivant le BA.B.A du développeur web.

Maintenant, je suis conscient du fait qu'un jeu sera évidemment victime d'attaques...mais nous faisons aussi des sites de jeu, dans ma boîte, où tu peux gagner de gros lots. Et crois-moi, ça attire les convoitises...des essais d'attaque, on en subit. Mais ce n'est pas si facile que tu as l'air de le croire, de pirater un site correctement codé (juste correctement, sans aller chercher des solutions miracles complexes).

cs_zeguizmo · Answer

Pour le referer, à moins que je n'ai rien compris, je pense que tu te trompes. Le code que j'ai fourni dans ce post même te montre comment émuler un referer sans le moindre souci. Il me semble que le referer est envoyé par le navigateur dans les headers ... Ecraser les headers par un script php est facilement faisable, comme mon code le monde. Sans toucher à un cheveu du navigateur de la cible. Juste en le faisant cliquer sur un lien, le mauvais referer est passé. Le code suivant (que j'ai déja donné dans ce post) te permet d'emuler un referer. Tu n'as qu'a le modifier pour qu'il tourne sur ton serveur favori et le tester.

<?php
    echo'Ici une page de mon site, en cliquant sur le lien A, on affiche le bon referer, en cliquant sur le lien B, on émule le referer 

    [test.php?action= lienA LIEN A] 

    [test.php?action=lienB LIEN B] 

    Le referer est : '.$_SERVER['HTTP_REFERER'];
    
     if  ($_GET['action'] == 'lienA')
    {
        header("Location: ./test.php");
    }
     else if  ($_GET['action'] == 'lienB')
    {
        $host = "localhost/test"; 
        $file = "test.php";        $hdrs array ( 'http' > array(
            'metod' = > "GET",
            'header'=> "accept-language: fr
" . 
            'Referer:

malalam · Answer

Encore une fois, un SID a une durée de vie très courte...ton exemple extrème implique non seulement une action de ton utilisateur, mais aussi une réaction très rapide du hacker. C'est tiré par les cheveux.

cs_zeguizmo · Answer

Et pour répondre a Malalam : 

T'as peur qu'un mec se connecte à distance en attaquant ton site en GET ? Il ne pourra le faire que sur SON compte.
Tu as peur qu'un robot attaque tes url sans cesse et fasse tomber ton site ? Ben ça, ça peut t'arriver avec un bête index.php.
Tu as peur qu'un robot fasse des milliers d'inscriptions à la suite sur ton site ? Un captcha bien foutu sera une bonne parade.

Visiblement je m'exprime tres tres mal, ce n'est pas du tout de ca dont il sagit.
Lis le dernier message, j'y détaille le probleme d'une facon plus claire.

Je  n'ai clairement pas ton niveau en php, ni ton expérience. Je travaille en stage (bac+4) dans une boite de dev de site web. J'ai soumis ma question au responsable informatique de l'ensemble des projets de la boite, il m'a répondu qu'il aimerait bien connaitre la solution de mon probleme si toutefois j'en trouvais une...

ZeGuizmo

cs_zeguizmo · Answer

Tu réponds toujours quand je suis en train d'écrire ;) Il faut lire mes réponses avec un décalage d'un message.

C'est tiré par les cheveux, je le reconnais, mais tu reconnais qu'une faille existe si cet exemple est applicable ? Un mec qui n'a que ca a foutre de ses journées pourrait éventuellement tirer parti d'une telle faille, non ?

Puis-je me prémunir de ce genre d'attaque ?

ZeGuizmo

malalam · Answer

Je suis désolé, mais tes exemples sont tjrs tirés par les cheveux.
Ton exemple sur google l'est. Evidemment que c'est le cas! Mais dans ce cas, Linux, Windowd, ou n'importe quel logiciel a les mêmes failles: si un utilisateur lance un .bat contenant un formatage du disque C, il risque de  gros ennuis. Tu estimes que c'est une faille de sécurité toi ? A ce compte, développe sur une vieille consome : là, tu es sûr que rien ne pourra arriver.

Et quand bien même un lien pourrait déconnecter tes utilisateurs de ton site, ça change quoi ?? C'est grave ça ? Et tu crois vraiment que ton site sera suffisemment connu pour que des milliers de sites proposent des liens dconnectant tes utilisateurs s'ils cliquent dessus...? Remarque, je te le souhaiote hein...mais même si c'était le cas, où esl le problème...?? Ce ne sont pas des attaques! Déjà. Et se prémunir contre des attaques...ca fait plus de 10a que je suis dans le dév web, et je n'ai jamais eu de problème. A moins que tu ne considères que des liens vers ton site sans passer par ta page d'accueiul ne soit un  problème (je suis encore désolé, mais ce que tu me dis me fait penser à ce genre "d'attaques").
Bref, je ne comprends pas où tu veux ev venir : tu ne parles pas d'attaques là, mais de possibilités qui n'ont aucune incidence. Et oui, ces possibilités existent, c'est normal, et il n'y a pas de problème de sécurité là-dedans. Si tu me disais que n'importe qui pouvait se logger sur ton site avec le compte de n'importe qui, ok...là, il y a problème. mais rien de ce que tu énonces ne pose le moindre problème de sécurité. Tu parles de liens vers ton site! Heureusement qu'on peut en faire, le web vit de ça.

malalam · Answer

C'est en effet un dialogue de sours parce que tu ne veux pas entendre ce que nous te disons : les "risques" dont tu parles n'existent pas. Dans tous tes message,s je n'ai pas vu le moindre véritable risque;  juste des  comportements HTTP normaux qui ne comportent aucun problème de sécurité. C'est ce que j'essaye de t'expliquer depuis le début. Tu pourras essayer de solidifier un coffre fort autant que tu voudras, il y a 2 vérités :
- un coffre fort est DEJA sécurisé
- que quelqu'un puisse s'appuyer sur la porte du coffre fort est un fait, mais ne comporte aucun risque
- tu pourras renforcer autant que tu veux le coffre fort (c'est tjrs possible), tu n'arriveras jamais à rien de parfait.

Si  la métaphore ne te parle pas, tant pis, j'abandonne.

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

17 réponses

Votre réponse

Discussions similaires