Proxy pour Secure ArcGIS Server Services. Sécurise?

Pour accéder à des services sécurisés (basés sur des jetons ou des informations d'identification), Esri recommande d'utiliser des fichiers proxy ( exemple .net github ). Lorsque vous acheminez des demandes via le proxy, vous pouvez demander des services sécurisés au nom du client sans exposer vos informations d'identification. Vous pouvez définir une propriété appelée allowedRefererset attribuer une liste d'URL de référence pour lesquelles le proxy fonctionnera. Fondamentalement, le proxy ne fera aucune demande de renvoi d'URL non définies. S'il est défini sur '*', toute demande de renvoi sera traitée.

Le problème est; l'en-tête demandeur peut être usurpé facilement par un pirate en définissant simplement une fausse propriété HTTP Referer . Dans cette situation, ils peuvent accéder à des services sécurisés en acheminant toutes leurs demandes via le proxy et en définissant l'en-tête du référent sur une adresse valide.

Je recherche des recommandations sur la meilleure façon de contourner ce problème. Des recommandations?

— jOshT
source

Grande question. Nous venons juste de l'expérimenter récemment et nous sommes tristes de constater que cela est probablement moins sûr que de passer un jeton à travers la chaîne de requête. Comme vous l'avez souligné, vous pouvez simplement transmettre des demandes via le proxy. Nous avons pu le vérifier avec seulement quelques lignes de code Python ... Nous avons pu parcourir l'intégralité de notre répertoire de services sans informations d'identification. Au moins avec le jeton transmis avec la demande, le jeton doit d'abord être activé / récupéré, ce qui me semble un peu plus sûr. Je suis également curieux de savoir si quelqu'un a de bonnes suggestions.

— crmackey

"Esri recommande ...": voir blogs.esri.com/esri/supportcenter/2015/04/07/setting-up-a-proxy . Semble bon de citer un incident desdites recommandations.

— gischimp

Merci gischimp. Ceci est une bonne ressource pour configurer le proxy, mais il ne fait référence à aucune méthode pour sécuriser le problème que nous rencontrons. Je sais que Portal et ArcGIS Online ont tous deux oAuth2. Je me demande si la prochaine version d'ArcGIS Server prendra en charge cela? Pour l'instant, il semblerait que @crmackey soit correct; la méthode la plus sécurisée (au moins pour les services basés sur des jetons) consiste à ne pas utiliser le proxy et à simplement attacher le jeton à la demande GET.

— jOshT

Il convient également de mentionner que vous pouvez ajouter le jeton aux cookies à l'aide de la agstokenclé. Cela n'ajoute pas beaucoup de sécurité supplémentaire, mais au moins le jeton n'apparaît pas dans la chaîne de requête.

— crmackey

Réponses:

J'héberge le proxy Java dans Apache Tomcat qui fournit une page de connexion. Le proxy ArcGIS s'exécute dans le même contexte d'application que la page de connexion. De cette façon, mes utilisateurs ont accès aux informations d'identification stockées dans une base de données distincte et sécurisée. Tomcat effectue la gestion de session habituelle tandis que le proxy ArcGIS légèrement modifié gère les informations d'identification et les jetons ArcGIS cachés. Tout cela se fait via HTTPS.

Le résultat est que:

Les informations d'identification ArcGIS ne sont jamais transmises en dehors de l'intranet local.
Les utilisateurs ne peuvent pas accéder au proxy sans une session valide.
Les sessions valides ne sont délivrées qu'aux utilisateurs disposant des informations d'identification appropriées.

— C. David Gibson
source

Lorsque vous acheminez des demandes via le proxy, vous pouvez demander des services sécurisés au nom du client sans exposer vos informations d'identification.

Je pense que cette phrase est la clé. Lorsque le proxy s'authentifie auprès du serveur SIG, le proxy est-il configuré avec des informations d'identification? Si tel est le cas, et que ces informations d'identification ont accès au service de carte demandé, il semblerait que cela "fonctionne comme prévu".

Si le proxy stocke / transmet des informations d'identification, le proxy est plus soucieux de sécuriser les informations d'identification que de sécuriser les données. Imaginez un site intranet d'entreprise qui affiche les données cartographiques d'un service de carte sécurisé.

l'en-tête demandeur peut être usurpé facilement par un pirate

La déclaration ci-dessus signifie-t-elle qu'un attaquant extérieur peut atteindre votre proxy directement? Si c'est le cas, vous avez plus à vous soucier qu'un en-tête HTTP usurpé.

Les utilisateurs, le proxy et le serveur SIG sont-ils tous à l'intérieur de votre réseau ou les utilisateurs utilisent-ils le proxy pour se connecter aux services SIG en dehors du réseau? La connaissance de certains détails de la topologie de votre réseau pourrait vous aider à obtenir de meilleures réponses.

modifier: Si vous avez une application Web publique qui récupère des ressources à partir d'un serveur SIG sécurisé à l'intérieur d'un réseau, vous souhaitez probablement un proxy inverse plutôt qu'un proxy direct.

— Mintx
source

Je pense que @jOshT partage les mêmes préoccupations que moi, à savoir qu'il ne semble y avoir aucun moyen de protéger les points de terminaison REST contre les visiteurs indésirables. Oui, le proxy masque les informations d'identification, mais si vous connaissez l'URL du proxy, vous n'avez même pas à vous soucier des informations d'identification, car vous pouvez simplement acheminer toutes vos demandes via le proxy et les informations d'identification sont transmises à l'arrière. J'ai testé cela avec quelques lignes de Python .

— crmackey

Je conviens que le proxy fait un bon travail pour garder les informations d'identification sécurisées. Lorsque vous dites «accédez directement au proxy»; Je dirais en quelque sorte. L'application est publique (tout comme le proxy), mais quelqu'un ne peut pas réellement "voir" le contenu de mon proxy (.net). Prenons par exemple un exemple Esri developers.arcgis.com/javascript/samples/ags_traffic . Ici, ils utilisent un proxy pour accéder à des services sécurisés. À l'aide des outils réseau de développeur Chrome, je peux simplement copier la demande (cURL) et l'exécuter à partir de la ligne de commande pour obtenir les informations. Comment sécuriser le proxy lui-même?

— JOshT

@jOshT Pourriez-vous coller votre fichier proxy.config et effacer les bits sensibles? Bien que d'après votre commentaire, il semble que vous feriez mieux avec un proxy inverse au lieu d'un proxy direct.

— Mintx

@Mintx Mon proxy est fondamentalement le même que celui d'Esri ici: github.com/Esri/resource-proxy/tree/master/DotNet sauf que j'ai défini AllowedReferers sur l'URL de l'application demandeuse.

— jOshT