Seguridad de conexión del servidor de aplicaciones

0

Tengo este proyecto escolar mío que involucra una aplicación y un sitio web que usa la misma base de datos. La aplicación sirve como una herramienta de administración para el sitio web. Dado que está hecho en C # y no es tan seguro como PHP, decidí que la aplicación interactúe con la base de datos a través del sitio web:

En el sitio web, hay un archivo php utilizado para establecer un enlace entre la aplicación y la base de datos. Este es el algoritmo que configuré para que esté lo más seguro posible:

  1. El usuario ingresa una contraseña en la aplicación, la envía al archivo php como un parámetro (/get.php?pwd=1234)
  2. El sitio web envía un token (llámalo T0) a la aplicación
  3. La próxima vez que la aplicación quiera enviar una consulta al sitio web, envía el md5 de T0 (llámelo T1), el sitio web en su lado calcula el md5 de T0 y lo compara con T1
  4. La siguiente consulta debe enviarse utilizando el md5 de T1 (T2) y el El sitio web lo comparará con md5 de T1

Lo bueno de este método es que en el caso de un hombre en el medio (suponiendo que no sepa que usamos el md5 del token), leer la contraseña o T0, no servirá para nada. propósito.

Como medida de seguridad adicional, cada token utilizado se guarda en una base de datos separada que contiene la ubicación exacta del usuario, ip y la operación realizada con él.

Como no soy un experto en seguridad, quería saber cuán difícil es infiltrarme en este sistema. Gracias

    
pregunta vbtheory 08.12.2014 - 22:00
fuente

1 respuesta

5

Primero, ¿puedo preguntar por qué cree que la aplicación no es tan segura como el sitio web? En términos generales, desde una perspectiva de seguridad, una de las peores cosas que puede hacer es involucrar a PHP, que tiene más riesgos de seguridad que las otras tecnologías comunes combinadas.

Además:

  1. si está cualquier tráfico sensible desde la aplicación al sitio web, debe estar sobre HTTPS.

  2. no envía las contraseñas como parámetros de la cadena de consulta. Esto prácticamente garantiza que se registrarán en texto sin formato, incluso si se transportan a través de HTTPS. Entonces necesita POSTAR como valores de formulario en su lugar.

  3. Hashing the token no hace mucho por ti. Si lo está enviando a través de HTTPS, un MitM no puede obtenerlo. Si no lo eres, un atacante puede generar un MD5 tan fácilmente como puedas.

  4. Guardar las fichas utilizadas es una buena idea, desde una perspectiva anti-reproducción. Realmente no necesita guardar la información auxiliar ... Tomará espacio de almacenamiento y probablemente no le dará mucha información útil.

  5. Sin embargo, guardar los tokens puede ser un problema si no usas HTTPS, porque un atacante que conoce tu esquema (y debes asumir que un atacante sabrá tu esquema) puede pre-calcular el siguiente token y secuestrar la sesión en adelante, no solo suplantando la aplicación real, sino también eliminando la aplicación real, porque cuando envía los siguientes tokens, ya estarán en la tabla de tokens usados.

Es probable que haya otros problemas aquí, pero estos son los primeros que he visto.

La conclusión es que creo que este esquema necesita un replanteamiento y un viaje de regreso al tablero de dibujo.

    
respondido por el Xander 08.12.2014 - 22:37
fuente

Lea otras preguntas en las etiquetas