En pro de la reutilización de componentes, así como de las buenas prácticas de arquitectura de componentes, muchos desarrolladores/arquitectos promueven la reutilización de servicios de presentación para ámbitos distintos de una misma aplicación o aplicaciones distintas, sin embargo en algunos casos esto no es siempre atendido de la mejora manera dando apertura a algunas brechas de seguridad difíciles de diagnosticar o detectar si no es en el diseño, ya que las pruebas de penetración no suelen contemplarlos, a continuación comentamos un poco más sobre
¿Cómo la reutilización o las buenas prácticas aplicadas sin el cuidado adecuado pueden caer en malas prácticas o antipatrones?
A continuación un poco del tema.
¿Que pasa cuando tenemos una aplicación o servicio que hace bien su trabajo y además está bien estructurado en su concepción original?
Tendemos a reutilizarlo para otras funciones o secciones de la aplicación u otras aplicaciones, cosa que de entrada y por si solo es buena idea y práctica, sin embargo si no se analizan los nuevos entornos, funciones o necesidades puede ser que el reutilizarlo sin cambios o con cambios básicos nos lleve a las siguientes brechas de seguridad:
- Proporcionar información innecesaria
- Para el flujo
En este caso un servicio que funciona correctamente en un escenario se reutiliza para obtener sólo ciertos campos de la respuesta, pero el servicio entrega toda la información al componente de presentación que es el encargado de filtrar. Alguien puede acceder a la información sin filtro que no necesariamente deba estar en esa parte del flujo o incluso en la aplicación. - Para el perfil
Al igual que el caso anterior que el filtrado de información del servicio se haga del lado de presentación y que alguien tenga acceso a información que el perfil no debería visualizar (reportes, estados, etc.). Casos de «escalamiento de privilegios»
- Para el flujo
- Acceso al servicio por perfiles no permitidos
Cuando el servicio es reutilizado son una adecuada refactorización en más aplicaciones que para la que fue diseñado, es muy común que no se molesten a perfilar el acceso al servicio y se limitan a llamarlo sólo en los flujos necesarios, sin embargo el acceso se deja abierto a cualquier perfil, que con su credencial de autenticación y conociendo la ruta del servicio puede invocarlo y con eso acceder a la información - Fugas de información sensible
Cuando los servicios proporcionan información sensible y los casos anteriores se presentan, un atacante puede obtener la información sensible de las personas para uso indebido, en estos casos normalmente los atacantes suelen automatizar el acceso para traer la mayor cantidad de información posible antes de que se detecte la brecha.
Por lo anterior y otras casuísticas es importante que antes de decidir reutilizar un servicio o endpoint que funciona correctamente pase por un proceso de análisis y refactorización que permita identificar y mitigar cualquier vulnerabilidad.
¿Pero que no para eso son las pruebas de penetración y seguridad?
La respuesta directa es sí, pero hay un grupo grande de casos en los que la falta de claridad de funciones o falta de interés del aplicador de las pruebas no cubren la totalidad de los casos. Para los casos expuestos ahondamos un poco sobre el porqué no siempre pueden ser la solución
- Proporcionar información innecesaria
En estos casos para que una buena prueba de penetración y seguridad funcione, se debe tener trazados todos los datos estrictamente necesarios en cada paso del flujo con el diccionario de datos, además del novel de acceso por perfil, de forma tal que al invocar un flujo la parte de invocación del servicio no sea por presentación sino por endpoint y que los campos de respuesta sean mapeados en el diccionario de datos, el flujo y el perfil, detectando que esa información no fuera entregada. ¿Cual es el contra? Hacer esto para cada endpoint no suele ser costeable en todos los casos por lo que en muchos casos se limitan a hacer las pruebas a nivel de flujo funcional y presentación donde estos problemas no son visibles. - Acceso al servicio por perfiles no permitidos
En este caso la solución anterior es parte de la solución, pero no necesariamente para la solución completa ya que puede ser que para un perfil específico no se requiera el llamado del servicio, por lo que no se agrega y por ende se asume una prueba correcta, sin embargo si se hicieran pruebas de seguridad directamente al servicio podrían detectarse que tiene problemas de elevación de privilegios o de acceso a información no permitida en el diccionario de datos, esto implica tener pruebas de seguridad no por aplicación sino por endpoint independiente, lo cual eleva costos de planeación y ejecución de pruebas. - Fugas de información sensible
Aunado a los puntos anteriores, si los endpoints no han sido refactorizados es altamente probable que tampoco tengan limitantes de consumo o detecciones de automatización, por lo que la fuga de información suele presentarse y mantenerse por periodos largos de tiempo.
Por lo anterior y mucho más es importante tener presente un tiempo de análisis y refactorización para servicios que aunque funcionen correctamente, no fueron pensados desde el principio para reutilización, ya sea en multiples aplicaciones, distintos flujos y/o distintos perfiles.