Discussion:Cross-site request forgery

message: L'utilisation du referrer est une technique vulnérable puisque c'est un header falsifiable à volonté par l'agent utilisateur. Elle ne devrait pas être citée, ou avec un avertissement sur ce point.
: Merci. Zandr4[Moa ?] 23 novembre 2009 à 17:10 (CET)

message: Pour moi, une vérification du Referer peut se trouver utile et non falsifiable.
Je m'explique. Je sais que sur le fond, il s'agit d'une information malléable à souhait en forgeant soi-même la requête HTTP par exemple. Cependant, dans le cas d'une attaque CSRF, c'est le navigateur de la cible qui exécute la requête HTTP vers la page vulnérable. Or le pirate ne peut pas toucher à CETTE information, c'est à dire la valeur du Referer fournie par le navigateur de la victime.
En gros, on obtient ça:
L'utilisateur clique sur un lien piégé (par exemple) => Il est envoyé vers une page du pirate => La page utilise JavaScript pour poster automatiquement un formulaire vers une page cible du site vulnérable (exemple d'exploitation avec POST) => [A cet instant le Referer est égal à l'adresse complète de la page du pirate] => La page cible identifie le Referer et bloque la requête.
La technique de vérification du Referer s'appuie sur le fait que le pirate ne peut pas falsifier le Referer de sa victime.
82.239.142.85 (d) 13 juin 2010 à 00:42 (CEST)
replies: text: Exact, sur le plan de la théorie. En pratique, le pirate peut. Il y a eu des exploits avec Flash et Ajax je crois. Zandr4[Kupopo ?] 13 juin 2010 à 09:01 (CEST)

text: Ça fait un petit moment que je ne me suis plus amusé. Je viens de tomber sur ça, c'est pas super précis et ça date un peu, mais enfin, j'ai pas le temps de chercher partout... Zandr4[Kupopo ?] 13 juin 2010 à 16:22 (CEST)

text: Je peut être raté quelque chose aussi, mais dans le doc en question, Ajax est utilisé pour forger la requête HTTP avec un referer falsifié, non ? Zandr4[Kupopo ?] 13 juin 2010 à 18:30 (CEST)

text: Je suis d'accord. Il me semblait avoir lu quand même que le referer pouvait être falsifié, lors d'une requête effectué par le navigateur dans le cadre d'un CSRF classique, grâce à flash. Si je me souviens bien, c'était avec FF qu'il y avait un problème. Mais vu que c'est un exploit logiciel, ce n'est pas une raison pour ne pas citer l'utilisation du referer, surtout que je ne retrouve plus rien là dessus. Je te laisse modifier l'article. Zandr4[Kupopo ?] 14 juin 2010 à 22:58 (CEST)

text: Les navigateurs (avec leur mode de navigation privée, par exemple) et certains logiciels de sécurité proposent de ne pas fournir de « referer » (ou d'en fournir un faux) pour des raisons de vie privée. Ainsi, dans ces cas, les protections utilisant l'en-tête HTTP « referer » s'avèrent inefficaces et peuvent même conduire à un blocage non-désiré du service web. Jcbrinfo (d) 11 août 2010 à 16:55 (CEST)
replies: text: Que veux-tu dire par inefficaces ? Dans le cadre que tu décris, il faut que l'utilisateur soit volontaire pour être victime. Zandr4[Kupopo ?] 11 août 2010 à 18:00 (CEST)
replies: text: Comme un autre membre a écrit plus haut, les protections qui utilisent le "referer" sont inefficaces puisque l'on se fit à une information falsifiable. Mon précédent message n'avait pour but que de prouver que le "referer" n'est pas une donnée fiable. De plus, si on bloque un service quand le "referer" n'est pas le bon, on empêche les utilisateurs soucieux de leur vie privée d'utiliser le service. JCBR Info (d) 22 août 2010 à 03:44 (CEST)

text: J'ajoute ici le bout de texte que j'ai mis en référence dans l'article principal au cas où tu ne l'aurais pas lu: "[...] Cette valeur est affectée par le client, et tous les clients ne le font pas. 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. " --JCBR Info (d) 22 août 2010 à 05:36 (CEST)
replies: text: Je sais bien. Mais dans le cadre d'un CSRF, que reproches-tu à l'argumentation de l'ip ci-dessus ? Zandr4[Kupopo ?] 22 août 2010 à 10:34 (CEST)
replies: text: De quelle "argumentation de l'ip" parles-tu? L'en-tête "referer" est un URI et non pas une adresse IP. "The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.)" (RFC 2616) Je te rappelle aussi qu'en mode de "navigation privée", les navigateurs ne fournissent pas le "referer", comme quand l'utilisateur tape l'adresse lui-même. --JCBR Info (d) 22 août 2010 à 21:54 (CEST)
replies: text: Je parlais de l'argumentation de l'ip qui a lancé cette discussion (qui a créé la section En ce qui concerne le Referer, juste au dessus de la notre qui signe d'ailleurs Gabriel Ladet (Gabilo). Peux-tu me décrire une situation où un site web utilise une protection par referer, et où quelqu'un utilisant un mode de navigation privé pourrait être victime d'une CSRF ? Je dis bien victime, pas juste ne pas pouvoir parcourir le site parce qu'il est refoulé pour cause de mauvais referer par exemple. Zandr4[Kupopo ?] 23 août 2010 à 01:12 (CEST)
thread_title:  En ce qui concerne le Referer 

message: Le document dit :
:« Le nombre de sites se protégeant contre ce type d'attaque est encore marginal, faute de communication sur ce type d'attaque probablement »
En tous cas, pas les forums PHPBB. L’attaque de Alice faite en utilisant Bob n’y fonctionnerait pas, dut à la validation de la cession par un identifiant de cession dans l’URL + par partie ou totalité de l’adresse IP de l’utilisateur. J’ai une difficulté à croire que les sites se protégeant sont marginaux. --Hibou57 (d) 24 juillet 2011 à 23:44 (CEST)
replies: text: J'ai supprimé la phrase, elle n'est de toute façon ni précise ni sourcée alors... Zandr4[Kupopo ?] 25 juillet 2011 à 10:39 (CEST)
thread_title:  « Le nombre de sites se protégeant est marginal »