Conexión segura entre cliente y servidor

Estoy desarrollando un componente de servidor que atenderá las solicitudes de un cliente incorporado, que también está bajo mi control.

En este momento todo es beta y la seguridad funciona así:

  1. cliente envía nombre de usuario / contraseña a través de https.

  2. El servidor devuelve el token de acceso.

  3. el cliente realiza más solicitudes sobre http con el token de acceso en un encabezado personalizado.

Esto está bien para una demostración, pero tiene algunos problemas que deben solucionarse antes de lanzarlo:

  • Cualquiera puede copiar una solicitud de login , reenviarla y obtener un token de acceso. Como algunos usuarios respondieron, esto no es un problema ya que pasa por https. Mi error.

  • Cualquiera puede escuchar y obtener una clave de acceso con solo inspeccionar los encabezados de solicitud.

Puedo pensar en un cifrado de clave simétrica, con una marca de tiempo, por lo que puedo rechazar solicitudes duplicadas, pero me preguntaba si existen algunas buenas prácticas bien conocidas para este escenario (eso parece bastante común).

Muchas gracias por la perspicacia.

PD: estoy usando Java para el servidor y el cliente está codificado en C ++, por si acaso.

No obtengo la primera parte. Si la solicitud de inicio de sesión es https, ¿cómo puede alguien copiarla?

Con respecto a la segunda parte, t Este es un escenario de secuestro de sesión bastante estándar. Vea esta pregunta . Por supuesto, aquí no tiene las opciones de navegador integradas, pero la idea básica es la misma: enviar el token solo a través de una conexión segura cuando sea importante, o asociar de alguna manera el token con el dispositivo de envío.

En un navegador, básicamente todo lo que tiene es una dirección IP (que no es muy buena), pero en su caso, puede express algo específico sobre su dispositivo que valida contra la solicitud para asegurarse de que no se esté utilizando el mismo token. utilizado desde otro lugar.

Edición: puede tener suerte aquí y ser capaz de descartar el cambio de dirección IP detrás de los proxies y usarla para este propósito.

Pero al final del día, es mucho más seguro usar https de una biblioteca conocida y revisada en lugar de intentar rodar la suya aquí. Me doy cuenta de que https es una sobrecarga, pero hacer rodar los suyos conlleva grandes riesgos si se pierden cosas obvias que un atacante puede explotar.

Primera pregunta, solo para que salga a la luz: si está lo suficientemente preocupado por los infames accesos de imitadores de clientes, ¿por qué no llevar a cabo toda la conversación a través de HTTPS? ¿Es el impacto mínimo lo suficientemente importante para esta aplicación que no vale la pena agregar la capa de seguridad?

Segundo, ¿cómo puede alguien repetir la solicitud de inicio de sesión? Si no me equivoco, eso está ocurriendo a través de HTTPS; Si la conexión está configurada correctamente, HTTPS previene los ataques de reproducción utilizando nonces de una sola vez (consulte aquí ).

Una de las recomendaciones comunes es – usar https

El hombre https en el ataque central aparte de usar https para toda la sesión debería ser lo suficientemente confiable. Ni siquiera necesita preocuparse por los tokens de acceso: https se encarga de esto por usted.

El uso de http para futuras solicitudes parece introducir algunas vulnerabilidades. Ahora, cualquier persona con un rastreador de red puede interceptar su tráfico, robar el token y falsificar sus solicitudes. puede crear protección para evitarlo: cifrado de token, uso de tokens de una vez, etc., pero al hacerlo volverá a crear https.

Volviendo al https man en el ataque central, se basa en la capacidad de alguien para insertarse entre su servidor y su cliente y canalizar sus solicitudes a través de su código. Todo es factible, es decir, en caso de que el atacante tenga acceso a la red física. El problema al que se enfrentará ese atacante es que no podrá otorgarle un certificado digital adecuado; no tiene la clave privada que usó para firmarla. Cuando se accede a https a través de un navegador, el navegador te da una advertencia, pero aún así te permite acceder a la página.

En su caso, es su cliente quien se comunicará con el servidor. Y puede asegurarse de que todas las validaciones adecuadas del certificado estén en su lugar. Si haces eso deberías estar bien

Editar

Secundaria a Yishai: sí, se trata de una sobrecarga, principalmente de la CPU, pero si esta sobrecarga adicional empuja a su servidor, tiene mayores problemas con su aplicación