Información de identificación personal en el parámetro de consulta para el servicio REST de Tomcat

6

Tengo una API REST en ejecución en un contenedor Tomcat que tiene un punto final que toma una dirección de correo electrónico del cliente como un parámetro de consulta. Es algo como esto:

/[email protected]

Las direcciones de correo electrónico de los clientes son un activo que queremos proteger, por lo que debemos asegurarnos de que no se registren en ningún lugar y que no puedan interceptarse. La API solo funciona a través de HTTPS y requiere una autenticación sólida.

Cuando se trata de registro, en el código de la aplicación, las direcciones de correo electrónico no se registran. Sin embargo, todas las URL del servicio se desconectan en el localhost_access_log de Tomcat, que incluye los parámetros de consulta. Un plan es utilizar una válvula de registro de acceso de Tomcat diferente que no cierre los parámetros de consulta en las URL. ¿Sería eso suficiente para garantizar que las direcciones de correo electrónico no se desconecten? ¿Hay algún otro lugar que normalmente cierre la sesión de las URL que deben ser atendidas?

    
pregunta oggmonster 15.07.2015 - 10:38
fuente

2 respuestas

1

Es muy probable que haya otros servicios que actúen como servidores proxy o de servidor o como equilibradores de carga en esta arquitectura. Estos manejan las solicitudes de envío a través de un grupo de Tomcats, cualquiera de los cuales puede no ser capaz de atender las solicitudes debido a la implementación o el mantenimiento u otra razón.

Todos esos servicios tendrán registros de acceso similares, ya sea escritos en archivos de registro o en servicios de registro de sistema local, que pueden enviarse a agregadores de registro de terceros o hacer copias de seguridad de los servicios de respaldo o en cualquier otro lugar.

En general, no es posible mantener los componentes de la "línea de solicitud": método, URI, cadena de consulta, versión HTTP fuera de todo tipo de almacenamiento duradero.

    
respondido por el Jonah Benton 17.09.2016 - 02:01
fuente
1

Como señaló Jonah B, generalmente es imposible mantener limpios todos los componentes de la "línea de solicitud".

Existe una técnica mucho más segura: no utilice la PII en la solicitud, sino que utilice un valor asignado para ella.

Entonces, en lugar de /[email protected] , tendría, por ejemplo, /customers?email=a4kl3delmze , donde a4kl3delmze es generado aleatoriamente por el servidor en el momento de la creación. Usar un valor como el hash del correo electrónico también podría funcionar.

El punto es: el valor del parámetro se asigna al correo electrónico en la base de datos, por lo que aún puede ejecutar su lógica de negocios pero no transfiere el valor de la cadena de correo electrónico con sus solicitudes

    
respondido por el niilzon 14.02.2017 - 14:46
fuente

Lea otras preguntas en las etiquetas