Necesito la aplicación 1 para hacer un POST en la aplicación 2, pero en la aplicación 2 debo asegurarme de que el POST proviene de la aplicación 1.
A los fines de esta publicación, llamaré a la aplicación 1 el Cliente , y la aplicación 2 es el Servidor .
Empecemos con:
Mi mayor preocupación es el ataque Man In The Middle.
Asegúrese de que cuando el Cliente realiza una conexión con el Servidor, el cliente debe confirmar la identidad del Servidor y asegúrese de que no haya ningún Hombre en el medio . (MITM) Este es el mismo problema que enfrentan los navegadores cuando intentan establecer una conexión segura para la Banca en línea u otras operaciones confidenciales.
-
Esto se asegura fácilmente utilizando un certificado HTTPS estándar (que usaría cifrado TLS). La conexión se asegura mediante el uso de criptografía asimétrica, de modo que la única forma de lograr MITM sería robar la clave privada del sistema de archivos del servidor.
Se puede emitir un certificado de una Autoridad de Certificación con renovación cada pocos años, o puede crear un certificado autofirmado almacenado en el sistema del Cliente sin costo alguno.
Ahora con la identidad del servidor, y MITM frustrado con éxito; solo necesita verificar la identidad del Cliente . Hay varias formas de proceder. Elige uno
-
Secreto compartido: simplemente incluya una contraseña en la máquina del Cliente, y el Servidor debe verificar que coincida. Esta es la forma más sencilla de verificar la identidad del cliente y es segura gracias a HTTPS.
-
Certificado de cliente como parte de la conexión TLS: aunque HTTPS proporciona un medio para los certificados de cliente, me parece más complicado de lo necesario.
-
Hora del día con cifrado: cree usted mismo una clave privada y pública de RSA por separado. Almacene la clave pública en el Cliente y el Servidor usará la clave Privada para descifrar. El cliente cifrará la hora del día y el servidor verificará que sea correcto. (dentro del rango)
-
Respuesta-desafío: en este caso, una clave pública RSA se almacena en el servidor y la clave privada en el cliente. El servidor envía una cadena aleatoria al cliente, junto con un ID de solicitud, y el cliente debe poder descifrar la información y enviarla de vuelta con el ID de solicitud correspondiente. Si el descifrado fue exitoso, entonces se verifica la identidad del cliente.
El beneficio que esto tiene sobre los demás es que, suponiendo, un atacante hackea con éxito su servidor y descarga archivos, no podrá hacerse pasar por un Cliente sin un truco más avanzado. (aunque estaría un paso más cerca de MITM) Con las soluciones 1, 2 y 3, simplemente descargar los archivos apropiados del sistema de archivos del servidor proporcionaría la información necesaria para hacerse pasar por un Cliente.
Las soluciones 3 y 4 se acompañan mejor con una protección contra los ataques de repetición. La solución 1 no es compatible con la prevención de ataques Replay. Sin embargo, en su caso de uso, utilizando HTTPS, creo que las repeticiones son solo un problema después de un corte exitoso del sistema de archivos del servidor, lo que permite MITM.
Bonus:
- Dirección IP: si es posible, haga que el Servidor verifique que la conexión se origine en una dirección IP del Cliente predeterminada. Si se verifica que la dirección IP del cliente no cambie, esta protección adicional proporcionará una gran protección contra cualquier ataque a las soluciones anteriores que he proporcionado.