Sin usar SSL, ¿cuál es la forma más segura de realizar una solicitud AJAX a una página de PHP?

3

Se sugirió una vez más en stackoverflow que intento mi pregunta aquí. Esto es literalmente:

Por lo tanto, es imposible realizar solicitudes AJAX de forma segura sin utilizar SSL. Lo entiendo. Puede ver en la fuente los datos que se envían a través de Javascript o puede acceder directamente a la página de PHP mediante la suplantación de encabezados, yada yada.

Pero digamos que esta aplicación web no requiere particularmente la seguridad verdadera , y en su lugar es solo un tipo de juego para mantener a raya a la mayoría de los ingenieros inversos. ¿Qué tipo de obstáculos debo emplear?

No estoy buscando una implementación de algoritmo de encriptación ridículamente exagerada de Javascript. Quiero simplicidad y seguridad moderada ... si eso no es contradictorio por naturaleza. Entonces, ¿qué recomendarían ustedes?

Por ejemplo, estoy realizando un concurso en el que si un usuario hace clic en una imagen correctamente (jQuery), pasa su ID de usuario y una marca de tiempo a una página de PHP, ambas MD5 procesadas por datos aleatorios y luego codificadas con MIME. La página PHP luego valida este ID de usuario y marca de tiempo, luego devuelve un "código" ganador en forma de otro hash MD5 con sal. También estoy empleando varias comprobaciones de encabezado para ayudar a garantizar que la solicitud se realice desde una ubicación válida. ¿Me estoy perdiendo algo, o es todo lo que puedo hacer? Parece que alguien podría simplemente disparar el evento jQuery click y arruinarlo todo, pero no veo cómo puedo evitarlo.

¡Le otorgaré la respuesta a cualquiera que tenga un ingenioso mecanismo de seguridad falsa! O ... solo quien me diga por qué soy estúpido esta vez.

    
pregunta daveycroqet 15.03.2012 - 14:22
fuente

4 respuestas

4

Específicamente, ¿contra qué estás tratando de protegerte?

¿Eavesdroppers está grabando o interceptando mensajes entre el cliente y el host? Básicamente, necesita SSL para asegurarse de que nadie pueda escuchar a escondidas, o crear su propio protocolo de encriptación (por ejemplo, como una extensión del navegador o javascript en la página), aunque lo recomiendo enérgicamente contra el método de encriptación para crear su propio (será más lento / débil y Sin duda, casi siempre tiene fallas importantes si no lo tiene examinado por varios expertos en criptografía). Concedido si sus usuarios solo tienen computadoras en redes separadas entre sí (y la máquina host) y no controlan redes intermedias (por ejemplo, trabajan en uno de sus ISP), no podrán escuchar a escondidas.

No estoy seguro de cuál es el objetivo de tu juego:

  

Por ejemplo, estoy realizando un concurso en el que si un usuario hace clic en una imagen correctamente (jQuery), pasa su ID de usuario y una marca de tiempo a una página de PHP, ambas MD5 procesadas por datos aleatorios y luego codificadas con MIME. La página PHP luego valida este ID de usuario y marca de tiempo, luego devuelve un "código" ganador en forma de otro hash MD5 con sal. También estoy empleando varias comprobaciones de encabezado para ayudar a garantizar que la solicitud se realice desde una ubicación válida. ¿Me estoy perdiendo algo, o es todo lo que puedo hacer? Parece que alguien podría simplemente disparar el evento jQuery click y arruinarlo todo, pero no veo cómo puedo evitarlo.

¿Hay varias imágenes y solo una imagen es correcta y solo se pueden adivinar una vez? Yo sugeriría que usaran un token de algún tipo de servidor.

Un proceso correcto sería (a) que usen sus credenciales secretas (nombre de usuario, contraseña) para solicitar un token de detección único (una cadena aleatoria única) del servidor. Luego hacen su conjetura (haciendo clic en una imagen) que envía el nombre de usuario, el token de conjetura y la imagen que eligieron. El servidor registra la imagen si el token de conjetura enviado era válido y no se ha utilizado anteriormente; de lo contrario, dice token no válido y arroja su respuesta. Esto todavía permite a un intruso descubrir la respuesta correcta.

    
respondido por el dr jimbob 15.03.2012 - 16:41
fuente
3

Esto parece más bien una cuestión de que un cliente manipule y active Javascript, lo que SSL no impide.

  

Parece que alguien podría simplemente disparar el evento jQuery click y arruinarlo todo, pero no veo cómo puedo evitarlo.

Eso es bastante correcto, las secuencias de comandos del lado del cliente, especialmente Javascript, son imposibles de bloquear contra cosas como la activación de eventos.

  

La página PHP luego valida este ID de usuario y marca de tiempo

Preveo errores debido a las diferencias de latencia / reloj (ya que Javascript se va a extraer de la PC local) dependiendo de la granularidad de su marca de tiempo, y de cuánta velocidad de avance / retroceso va a ver para ver si hay hay coincidencias adyacentes.

Además de tener el algoritmo que alguien realmente determinará buscará colisiones de hash debido a que el MD5 es terrible (si entiendo su implementación correctamente y solo estoy pasando los hashes).

Sin embargo, no importa lo que use para el cifrado, es una secuencia de comandos del lado del cliente, por lo que solo puedo disparar cualquier método que use para publicar los datos en su servidor o realizar una ingeniería inversa sencilla.

    
respondido por el StrangeWill 15.03.2012 - 16:18
fuente
1

Parece que su juego proporciona un comportamiento "similar a un cuestionario", donde hay un montón de lugares en los que el usuario puede hacer clic y solo uno de ellos es correcto. El servidor sabe cuál es el correcto y el acertijo para el jugador del juego es averiguar en cuál hacer clic. ¿Es eso correcto?

Parece que lo que está haciendo actualmente es enviar la solución al cuestionario (la ubicación del lugar correcto para hacer clic) al cliente, y usar Javascript en el cliente para verificar cada clic para ver si es correcto. Si parece ser correcto, entonces lo envías al servidor con alguna otra sustancia. Por supuesto, esto es intrínsecamente inseguro, porque si el usuario es malicioso, puede manipular el Javascript (o el entorno de ejecución de Javascript), mirar dentro de él, averiguar cuál es el lugar correcto para hacer clic y luego ganar la prueba.

La forma segura de hacer esto es hacer todas las comprobaciones de su solución en el servidor. No envíe la solución correcta al cliente. Cuando el usuario haga clic en una ubicación, envíe la ubicación al servidor a través de una consulta AJAX. Haga que el código del servidor verifique si el clic del usuario fue correcto o no, haga un seguimiento de esto y envíe una respuesta. De esa manera, sin importar cuánto se mezcle el usuario con el código Javascript del lado del cliente, no pueden ver la solución correcta y no obtienen ninguna ventaja al resolver el cuestionario.

La regla general es: puede controlar el servidor, por lo que si codifica correctamente la aplicación del lado del servidor, puede confiar en ella. Sin embargo, no puede controlar el cliente (el navegador está bajo el control del usuario, no de su control), por lo que no puede confiar en el cliente o el código del lado del cliente. Nunca confíe en el cliente: ponga sus controles de seguridad en el servidor.

    
respondido por el D.W. 15.03.2012 - 18:24
fuente
0

el siguiente libro es excelente en seguridad Ajax Seguridad Ajax , échale un vistazo

    
respondido por el P3nT3ster 21.03.2012 - 07:06
fuente

Lea otras preguntas en las etiquetas