2010-08-31 29 views
4

J'ai une application qui utilise des URL dynamiques plutôt hostiles la plupart du temps. Je fournis des URL conviviales pour certains contenus, mais ceux-ci ne sont utilisés que comme point d'entrée dans l'application, après quoi toutes les URL générées seront la variété hostile. Ma question est, si je sais que l'utilisateur est sur une page pour laquelle une URL amicale pourrait être générée et ils choisissent de la mettre en signet, est-il un moyen d'indiquer au navigateur de mettre en signet le gentil au lieu de ce qui est dans la barre d'adresse?Existe-t-il un moyen d'indiquer au navigateur de mettre en signet une URL différente de celle de la barre d'adresse?

+3

Contrôle-t-on l'application? Si oui, pourquoi ne pas rediriger les URL moche vers le côté serveur? – John

+0

Pensé à ce sujet, mais si j'allais faire cela, je changerais probablement l'application pour ne générer que des liens amicaux. Il y a plusieurs raisons pour lesquelles cela ne fonctionne pas vraiment pour mon application; pour une chose, je ne veux pas vraiment une redirection 302 pour chaque page à laquelle l'utilisateur navigue. Le maintien de règles de réécriture pour cette application s'avérerait également problématique. – BCG

Répondre

1

N ° Ceci est par nature, et une bonne chose. Imaginez le scénario suivant: Piskvor surfe sur http://innocentlookingpage.example.com/ et clique sur "signet". Il ne remarque pas que le signet qu'il a enregistré pointe vers http://evilsite.example.net/ La prochaine fois qu'il ouvrira ce marque-page, il pourrait avoir une petite surprise.

Un autre exemple sans problèmes inter-domaines: Piskvor clics du site admin « signet » sur la page d'accueil de http://security-holes-r-us.example.org/ - malheureusement, la page est vulnérable à l'injection de script et le code injecté change le signet à http://security-holes-r-us.example.org/admin?action=delete&what=everything&sure=absolutely. S'il est encore connecté la prochaine fois qu'il ouvre le signet, il peut trouver son site purgé de données (Accordé, c'était sa faute de ne pas empêcher l'injection de script ET d'avoir non-idempotent GET resources, mais c'est trop commun).

+0

Je suis d'accord avec le scénario que vous décrivez, mais je n'essaie pas de traverser les domaines ici, donc je ne pense pas que ce soit plus dangereux que les cookies de domaine ou SOP sur xmlhttprequest. – BCG

+0

@bgould: En effet. Je sais que vous ne voulez pas faire de mal, et vous le savez; mais la confiance est l'une des choses les plus difficiles à mettre dans le code, la bonne manière et sans failles de sécurité. Il est beaucoup plus facile (et par conséquent plus sûr) de coder "ceci n'est jamais autorisé" que "ceci n'est pas autorisé, excepté quand X, et aussi Y, mais pas quand Y et Z, et pendant une pleine lune". – Piskvor

1

J'avais espéré que rel="canonical" aiderait ici, mais il semble que c'est seulement utilisé pour l'indexation. Peut-être qu'un jour les navigateurs l'utiliseront.

+0

+1 car même si cela ne résout pas la question, j'ai besoin exactement de cette fonctionnalité pour l'indexation des moteurs de recherche. – BCG