Comment masquer une URL dans la barre de navigation

**tim1789** · 06/10/2010, 15h35

Bonjour,
J'ai développé un site d'e commerce sur une base spip et php avec comme mode de paiement le script Atos pour la Société Générale. J'ai de temps à autre des tentatives bizarres, peut être de fraude bien que la méthode me semble douteuse, qui consiste à utiliser directement l'url de la réponse de la banque.

J'ai pensé à plusieurs solutions pour éviter que cela ne se produise trop souvent.

1) enregistrer l'ip

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$_SERVER["REMOTE_ADDR"]." ;

et dans le cas d'une tentative, afficher une page de mise en garde avec l'ip, mais cet ip ne donne que l'ip du FAI, et donc pas trop dissuasif. Je suppose que l'on ne peut être plus précis comme identification, l'idéal bien sûr serait d'envoyer un email de mise en garde qui serait dissuasif, mais probablement aucun moyen d'avoir l'adresse email (heureusement ! ), je n'ai pas de relation avec ADOPI !!!

2) ces visiteurs utilisent l'url de la réponse de la banque, c'est à dire qu'ils connaissent le chemin d'accès et le nom du fichier de réponse. Depuis longtemps, j'ai limité les possibilités de se balader dans ce répertoire par htaccess. Bon, il est possible que j'aie oublié quelques aspirateurs de site. Mais il existe une possibilité beaucoup plus simple de connaitre cette url, c'est de passer une commande et de l'annuler au dernier moment. De là l'intérêt de masquer les url qui correspondent à cette fonction. Est-il possible de masquer ces url (ou de les remplacer par des url fataisistes) et si oui, comment, en php. Évidemment, une redirection ne me serait d'aucune utilité.
Peut être y a t'il d'autres idées, merci d'avance pour une solution

**xbugzz** · 06/10/2010, 19h33

Salut,

Je ne sais pas comment éviter de connaitre l'URL en revanche tu peux toujours limiter l'accès une seule fois à cette page. Je suppose que l'utilisateur est identifié via une session ? Si oui, lors de l'accès a cette page, tu "tag" la session et contrôle au début de ce fichier que la session existe et qu'elle n'est pas taguée...?

**tim1789** · 06/10/2010, 22h23

Bien entendu, en utilisation normale, l'utilisateur parvient à la page de réponse bancaire après sélection d'article, identification... tout cela enregistré dans une session. Mais là, l'utilisateur vient directement sur cette page, sans passer par les pages de sélection et d'identification. Je ne sais pas pourquoi, je ne vois pas pour l'instant l'intérêt qu'il y a à faire cela, mais j'ai tout de même quelques craintes.

**Madfrix** · 06/10/2010, 23h10

Bonjour,

sinon tu peux tester avec $_SERVER["HTTP_REFERER"] la provenance du visiteur et le rediriger vers la page d'identification s'il ne provient pas de ton site sinon

**tim1789** · 07/10/2010, 18h10

Je crois bien que c'est une très bonne idée, ça résout bien mon problème sans masquer les url, merci

**sabotage** · 08/10/2010, 00h03

Attention, c'est le client qui fourni le HTTP_REFERER, c'est donc falsifiable a volonté.

**tim1789** · 08/10/2010, 23h17

Dommage, je croyais le tenir, dommage, mais on trouvera une solution !

**alpha232** · 10/10/2010, 17h38

Salut une possibilité serait d'utiliser une variable de session dans laquelle tu mémorise l'état de la commande client, si elle est nulle tu renvoie le client sur autre page quand il accède à la page de paiement? Pour autant que l'internaute ne tape pas directement l'url de la banque, parce que là tu n'aura aucune possibilité d'agir....

Alpha.

**tim1789** · 11/10/2010, 13h57

Je pense qu'il n'est pas possible de passer par une variable de session. J'ai essayé, mais il est probable qu'en lançant le script banque, on quitte le site pour revenir ensuite à l'adresse de retour indiquée, la session est donc close et la variable avec.

Quant à $_SERVER["HTTP_REFERER"], il ne retourne rien, j'avais cru trop tôt que c'était une bonne solution.

Bon, ce n'est pas grave, cela ne perturbe que la mise en mémoire des retours de transactions et je ne vois toujours pas comment on peut tenter une fraude de cette façon. Et puis, il faut bien garder quelques questions non résolues, histoire de continuer à réfléchir.
Merci.

**gene69** · 13/10/2010, 22h51

Je pense que tu n'as pas compris le mécanisme des sessions php.

la session "serveur" est conservé par ton script jusqu'à l'appel explicite par un de tes scripts d'une la fonction session_destroy.

On va dire que tu implémentes le session_destroy (perso je m'en passe). Tu ne peux le faire que lorsque le visiteur clique sur déconnecter. Sinon la session persiste pour une durée configurable (en heure ou en jour)

Pourquoi ton visiteur se déconnecterai avant d'aller payer??? ta session php sera fermée au bout de 24h pour les plus laxistes. ça marchera...

(surtout que c'est X heures apres la derniere utilisation de session_start() pour ce visiteur et non la premiere. Logiquement tu fais un session_start() en haut de chaque script... )

**tim1789** · 14/10/2010, 17h51

Je n'ai pas été assez précis et je me suis mal exprimé : c'est sur le retour de banque qu'un petit plaisantin tente de faire joujou, sans passer par la sélection d'article, l'identification et la saisie carte bancaire. Il n'y a donc pas de session ouverte.

Je pense avoir compris le mécanisme de session. J'ouvre une session au moment de la saisie article et cette session reste ouverte. Après la saisie bancaire, je fournit à la banque les informations nécessaires ainsi qu'une adresse de retour (la page 1 du site) en http://www..... et déclenche le script fourni par la banque. A ce moment, il y a transfert sécuritaire des infos, traitement bancaire.. et la banque redonne la main à l'adresse de retour fournie. Il est probable que pendant l'exécution du script, il y ait déconnexion du site, d'où fermeture de la session (l'adresse retour est en www.).

Ainsi,je ne peux utiliser une variable de session pour séparer un retour normal du bricolage décrit ci-dessus.

Finalement, ce problème semble peu important, et probablement sans risque, il perturbe simplement la mémorisation du retour bancaire. Les différentes solutions que j'ai envisagées et testées ne fonctionnent pas. En plus, le test est compliqué car le site est opérationnel.

Merci de vos contributions