Le mar. 11 sept. 2018 à 11:58, Pierre Beyssac <p...@fasterix.frmug.org> a écrit :
> On Mon, Sep 10, 2018 at 04:24:17PM +0200, Julien Lepiller wrote: > > Probablement un coup de la sécurité de firefox, j'ai le même souci avec > > HOT. En gros, il aime pas qu'on fasse une requête en HTTP depuis une > > page en HTTPS, donc il bloque. D'ailleurs, j'ai ce message (pas le même > > que HOT) en plus : > > > Blocage d’une requête multiorigines (Cross-Origin Request) : la > > politique « Same Origin » ne permet pas de consulter la ressource > > distante située sur > > > http://127.0.0.1:8111/load_and_zoom?zoom_mode=download&left=1.8996612&bottom=47.9166018&right=1.90061&top=47.9172378&select=way81016796,way297346084. > > > Raison : échec de la requête CORS. > > Ça peut être bloqué pour raisons de "Content Security Policy" en > effet mais normalement (selon leur propre doc) dans les Firefox > récents 127.0.0.1 est une exception qui ne devrait pas bloquer (je > n'ai pas essayé ::1). > C'est normal que ça bloque : ce n'est pas parce que le lien est activé dans un navigateur local que la source de ce lien vient du domaine local : la page vient d'un site tiers et le navigateur tient compte de l'origine de la page et de ses scripts, qui est le site web consulté affichant les liens. Sinon c'est trop facile pour une site web malveillant d'insérer des liens "127.0.0.1" pour passer outre les autorisations et obtenir directement des privilèges locaux (le javascript ne nécessaite pas forcément un clic de l'utilisateur pour se déclencher, le blocage est pour tous les scripts et liens). Bref si on veut éviter le blocage c'est à l'utilisateur d'ajouter une exception pour un site spécifique et l'autoriser à référencer des ressources locales (ou directement utiliser des fichiers locaux via 127.0.0.1 et rapporter le tout immédiatement au serveur web qui volerait les données). Le navigateur bloque donc tout à fait normalement ces scripts et si Firefox laisser passer, c'est une passoire, un gros trou de sécurité ! Bref le visiteur du site DOIT ajouter spécifiquement une autorisation pour permettre à un domaine web de suivre un lien local. En attendant ces liens sont désactivés et bloqués. Normalement le navigateur doit afficher une alerte de ce blocage (au minimum une icone dans la barre en haut), et pas seulement mettre une trace dans la console (qui n'est que très rarement affichée par la plupart des utilisateurs des navigateurs): cliquer cette icone doit indiquer la raison du blocage, et offrir un bouton éventuel pour permettre d'ajouter une exception pour le site web auquel l'utilisateur accorde sa confiance. Attention toutefois à ne PAS accorder une exemption totale de tous les sites web (IP, domaines, ou URL quelconques) pour leur donner accès au domaine local. La protection CORS est maintenant une nécessité absolue : chaque page, chaque script, chaque image est associée à un domaine qui définit son propre "royaume" de sécurité. Un site web peut déclarer qu'il ajoute des sites tiers à son royaume, mais n'a pas le droit de déclarer 127.0.1 ou d'autres ressources locales comme étant dans son domaine : une telle déclaration serait malveillante et le site web sera traité lui-même comme malveillant dans tout bon navigateur et ne pourra utiliser que ses propres ressources issues de son propre domaine ! Il y a d'autres restrictions aussi concernant non seulement les domaines mais aussi les protocoles : un site HTTPS ne doit plus accorder par défaut de droit aux ressources HTTP, même issues de son propre domaine, et donc le navigateur doit les bloquer: il appartient au site web de mettre toutes les ressources qu'il demande d'utiliser aussi en HTTPS ou dans un protocole sécurisé utilisant les mêmes certificats avec les autorisations compatibles et sinon s'assurer que les ressources de sites tiers (souvent des traqueurs, des pubs, des outils de géolocalisation) sont aussi en HTTPS si le site principal est en HTTPS (on voit l'anomalie récente sur les wikis de Wikimedia et OSM où un script de géolocalisation utilisait un site HTTPS qui maintenant va fermer et redirige vers une page en HTTP: ce script, bien, bien qu'hébergé par le wiki et chargé en HTTPS, et référençant une ressource HTTPS, ne peut pas honorer la redirection vers HTTP et se fait donc bloquer très légitimement par le navigateur, et c'est une très bonne chose à mon avis que les navigateurs renforcent l'isolation des sites en les séparant chacun dans leur propre bac à sable qu'ils ne peuvent "ouvrir" qu'en étant très strict sur la déclaration explicite des autorisations qu'ils accordent **eux-mêmes** à des tiers, sous leur propre responsabilité y compris légale).
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
