Je dois essayer d'usurper le HTTP_REFERER passé mon autre page de sorte que dans la page de destination, je peux déterminer de la demande vient de la "bonne" page et exécuter la logique appropriée.Comment usurper HTTP_REFERER?
TIA béliers
D'une manière générale, vous ne pouvez pas faire d'autres navigateurs pour revenir un faux HTTP_REFERER sans un exploit, ou autre extension plug-in. Si vous voulez modifier la valeur envoyée depuis votre navigateur Web et que vous utilisez FireFox, regardez l'extension Modify Headers.
Dans tous les cas, vous ne devez jamais compter sur HTTP_REFERER pour être précis. Il n'y a aucune garantie que le HTTP_REFERER que vous recevez n'est pas falsifié ou tout simplement pas envoyé.
Si vous souhaitez tester sur la page de destination si une requête provient de la page «droite», vous n'avez pas besoin d'usurper le référent. Tout ce que vous devez faire est d'émettre la demande à partir d'une page différente. Configurez une page à une URL différente de celle que vous considérez comme la «bonne» et lancez des demandes à partir de là, soit en cliquant sur un lien vers la page de destination, soit en plaçant une image provenant de la destination.
La page d'appel provient de l'application d'un client à laquelle je n'ai pas accès. Donc, au lieu de coder dans le noir, j'ai besoin de "spoofer" le référent et tester ma page. – rams
@Rob, Pourquoi lui dites-vous "vous n'avez pas besoin d'usurper le referrer"? Cela semble hors de propos car il demande comment le parrain peut être usurpé. – Pacerier
@Pacerier, il demande "Comment puis-je résoudre le problème X en faisant Y?"Ma réponse est qu'il n'a pas vraiment besoin de faire Y afin de résoudre X. Dans ce cas, X est de tester que la page peut détecter le référant, Y est d'usurper le référent –
Il a déjà été mentionné que vous ne pouvez pas vraiment usurper des choses. Mais pour clarifier, l'en-tête HTTP_REFERER est généré par le navigateur, donc sur le côté serveur des choses vous ne pouvez pas le contrôler (y compris les choses qui désactivent le javascript, qui peut ou non être activé). Si vous voulez juste tester la réponse de votre page à certains en-têtes (comme "Referer:"), vous pouvez utiliser des outils en ligne de commande comme curl ou wget qui sont disponibles dans la plupart des variantes BSD et Linux (y compris OS/X). Si vous utilisez MS Windows, vous pouvez obtenir curl ou wget en utilisant Cygwin.
wget -O - --referer="http://example.com/some/path" http://example.com/
ou
curl -e "http://example.com/some/path" http://example.com/
Mais votre principale raison pour ce faire est apparemment pour "protéger" une page, je pense. Si vous voulez vraiment vous assurer qu'une page (appelée "B") n'est visitée qu'après qu'une autre page ("A") a été visitée en premier, alors vous avez besoin d'une logique plus complexe du côté serveur.
Si vous stockez un cookie de session, vous pouvez intégrer une logique sur la page "A" qui définit une variable booléenne. Ajoutez ensuite une logique à la page "B" qui vérifie que la variable a été définie.
Je vais laisser cela au lecteur pour comprendre comment faire cela dans ASP.NET. (Parce que je suis un programmeur PHP. ;-))
Pourquoi dites-vous que le renvoi vérification ne peut pas garantir que "la page B n'exécute la logique qu'après avoir visité la page A"? – Pacerier
Si vous utilisez un cookie, vous pouvez vous assurer que le cookie est défini par une visite à la page A, et que B peut vérifier Le cookie HTTP_REFERER est généré par le navigateur, donc il ne peut pas être approuvé. – ghoti
merci pour le lien. Je vérifierai. – rams
Si vous utilisez l'extension Chrome [ModHeader] (https://chrome.google.com/webstore/detail/modheader/idgpnmonknjnojddfkpgkljpfnnfcklj), faites le travail! – GiDo