Proxy para Secure ArcGIS Server Services. ¿Seguro?

Para acceder a servicios seguros (basados en token o credenciales), Esri recomienda usar archivos proxy ( ejemplo .net github ). Al enrutar solicitudes a través del proxy, puede solicitar servicios seguros en nombre del cliente sin exponer sus credenciales. Puede definir una propiedad llamada allowedReferersy asignar una lista de URL de referencia para las que funcionará el proxy. Básicamente, el proxy no hará ninguna solicitud de URL de referencia que no estén definidas. Si se establece en '*', se procesará cualquier solicitud de referencia.

El problema es; un hacker puede suplantar fácilmente el encabezado solicitante simplemente configurando una propiedad falsa de referencia HTTP . En esta situación, pueden acceder a servicios seguros enrutando todas sus solicitudes a través del proxy y configurando el encabezado del árbitro a una dirección válida.

Estoy buscando recomendaciones sobre la mejor manera de solucionar este problema. ¿Alguna recomendación?

— JOSHT
fuente

Gran pregunta Acabamos de experimentar con esto recientemente y nos entristeció descubrir que probablemente sea menos seguro que pasar un token a través de la cadena de consulta. Como señaló, puede pasar las solicitudes a través del proxy. Pudimos verificar esto con solo unas pocas líneas de código Python ... Pudimos recorrer todo nuestro Directorio de Servicios sin credenciales. Al menos con el token pasado con la solicitud, el token tiene que ser activado / recuperado primero, lo que me parece un poco más seguro. También tengo curiosidad si alguien tiene algunas buenas sugerencias.

— crmackey

"Esri recomienda ...": ver blogs.esri.com/esri/supportcenter/2015/04/07/setting-up-a-proxy . Parece bueno citar un incidente de dichas recomendaciones.

— gischimp

Gracias gischimp. Este es un buen recurso para configurar el proxy, pero no hace referencia a ningún método para asegurar el problema que estamos teniendo. Sé que Portal y ArcGIS Online tienen oAuth2. Me pregunto si la próxima versión de ArcGIS Server admitirá esto. Por ahora, parece que @crmackey es correcto; El método más seguro (al menos para los servicios basados en token) es no usar el proxy y simplemente adjuntar el token a la solicitud GET.

— JOSHT

También vale la pena mencionar que puede agregar el token a las cookies utilizando la agstokenclave. Esto no agrega mucha seguridad adicional, pero al menos el token no aparece en la cadena de consulta.

— crmackey

Respuestas:

Alojo el proxy Java en Apache Tomcat que proporciona una página de inicio de sesión. El proxy ArcGIS se ejecuta en el mismo contexto de aplicación que la página de inicio de sesión. De esta manera, mis usuarios obtienen acceso con credenciales almacenadas en una base de datos segura y separada. Tomcat realiza la administración de sesión habitual, mientras que el proxy ArcGIS ligeramente modificado maneja las credenciales y tokens ocultos de ArcGIS. Todo esto se hace a través de HTTPS.

El resultado es que:

Las credenciales de ArcGIS nunca se transmiten fuera de la intranet local.
Los usuarios no pueden acceder al proxy sin una sesión válida.
Las sesiones válidas solo se emiten a usuarios con las credenciales adecuadas.

— C. David Gibson
fuente

Al enrutar solicitudes a través del proxy, puede solicitar servicios seguros en nombre del cliente sin exponer sus credenciales.

Creo que esta oración es la clave. Cuando el proxy se autentica en el servidor SIG, ¿está configurado con credenciales? Si es así, y esas credenciales tienen acceso al servicio de mapas que se solicitó, entonces parecería que está "funcionando según lo previsto".

Si el proxy está almacenando / pasando credenciales, entonces el proxy está más preocupado por mantener las credenciales seguras que mantener los datos seguros. Piense en un sitio de intranet de la empresa que muestra datos de mapas de un servicio de mapas seguro.

un hacker puede falsificar fácilmente el encabezado solicitante

¿La declaración anterior significa que un atacante externo puede comunicarse con su proxy directamente? Si es así, tiene más de qué preocuparse que un encabezado HTTP falso.

¿Los usuarios, el proxy y el servidor SIG están todos dentro de su red, o los usuarios están usando el proxy para conectarse a los servicios SIG fuera de la red? Conocer algunos detalles sobre la topología de su red podría ayudarlo a obtener mejores respuestas.

editar: si tiene una aplicación web pública que está obteniendo recursos de un servidor SIG seguro dentro de una red, entonces probablemente desee un proxy inverso en lugar de un proxy directo.

— Menta
fuente

Creo que @jOshT comparte las mismas preocupaciones que yo, que es que parece que no hay forma de proteger los puntos finales REST de los visitantes no deseados. Sí, el proxy oculta las credenciales, pero si conoce la URL del proxy, ni siquiera tiene que preocuparse por las credenciales porque solo puede enrutar todas sus solicitudes a través del proxy y las credenciales se pasan en el back-end. He probado esto con algunas líneas de Python .

— crmackey

Estoy de acuerdo en que el proxy hace un buen trabajo al mantener seguras las credenciales. Cuando dices 'llegar al proxy directamente'; Yo diría algo así. La aplicación es pública (como lo es el proxy), pero alguien no puede realmente "ver" el contenido de mi proxy (.net). Tomemos, por ejemplo, un ejemplo de Esri developers.arcgis.com/javascript/samples/ags_traffic . Aquí están usando un proxy para acceder a servicios seguros. Con las herramientas de red para desarrolladores de Chrome, puedo copiar la solicitud (cURL) y ejecutarla desde la línea de comandos para obtener la información. ¿Cómo se puede asegurar el propio proxy?

— JOSHT

@jOshT ¿Podría pegar su archivo proxy.config y dejar en blanco los bits sensibles? Aunque por su comentario, parece que es mejor que tenga un proxy inverso en lugar de un proxy directo.

— Mintx

@Mintx Mi proxy es básicamente el mismo que el de Esri aquí: github.com/Esri/resource-proxy/tree/master/DotNet, excepto que he configurado AllowReferers en la URL de la aplicación solicitante.

— JOSHT