He desarrollado una API REST que se ha configurado para funcionar solo a través de HTTPS. El único propósito de esta API (al menos por el momento) es operar como el punto de entrada de back-end para una aplicación móvil.
He lanzado mi propio protocolo de autenticación de token ( vea esta pregunta / respuestas ) que se utiliza para la autenticación del cliente. La razón principal detrás de esto fue poder generar tokens seguros / reutilizables que el cliente podría almacenar localmente & reutilizar en las solicitudes posteriores. Como tengo control sobre estos tokens del lado del servidor, tengo la capacidad de expirar / invalidar forzando al cliente a volver a autenticarse (es decir, generar un nuevo token) y también estoy tomando precauciones para evitar ataques como MitM / Replay. Para que esto funcione, tiene que pasar cierta información confidencial a través del cable en texto plano, sin embargo, todo se está ejecutando en SSL, por lo que AFAIK no hay nada de qué preocuparse aquí (?).
Hay un par de partes de esta configuración actual que sí me preocupan:
-
Para la autenticación del servidor, cuando la aplicación recibe el certificado del servidor (autofirmado) solo estoy comprobando si el asunto del certificado (por ejemplo, CN = nombre de dominio) es el mismo que la dirección API, es decir, si el punto de entrada de la API es api.mydomain.com, entonces debe recibir un certificado con un asunto CN = api.mydomain.com de lo contrario, la sesión de SSL fallará.
-
No hay protección desde el punto de vista del servidor contra solicitudes anónimas. La autenticación del cliente solo ocurre en el punto donde se inspecciona la información del encabezado / publicación. Creo que esto podría dejar la puerta abierta a los ataques de Dos. Lo ideal sería que el servidor solo acepte solicitudes que provengan de una fuente conocida .
Mi preocupación con el primer problema es que es demasiado fácil de eludir, la dirección de la API es configurable desde la configuración de la aplicación & cualquier persona puede generar un certificado autofirmado, por lo que sería bastante trivial engañar a la aplicación para que piense que está hablando con el servidor correcto. Sin embargo, el segundo problema es más una preocupación general. Sin embargo, si pudiera filtrar cualquier solicitud de cliente no autenticada, ¡sería una ventaja!
Lo único que viene a la mente a resolver (al menos el segundo problema) es presentar certificados de cliente. Mi preocupación con esto es el tiempo de implementación, la complejidad de la implementación y la administración de los certificados en sí mismos. Supongo que lo que estoy buscando es un consejo sobre si (según la configuración actual) la introducción de certificados de cliente en el dispositivo obtendría algo aquí?