Integrar la autenticación de PHP y WebSocket de forma segura

Question

Integrar la autenticación de PHP y WebSocket de forma segura

#1 de GxTruth (1 votos)

1

Tengo un servidor PHP que ejecuta un sitio web, y el sitio web tiene características como notificaciones en vivo, que básicamente son notificaciones que se le envían una vez que un usuario desea hacer un comentario sobre una de sus publicaciones, en vivo.

Decidí usar WebSocket para esto, solo para practicar. Para usar WebSocket, necesito autenticar al usuario y usar su información para obtener y entregar datos a otros usuarios conectados.

Etapa uno

Sé que PHP obtiene la identificación de sesión del usuario que ha iniciado sesión de las cookies y utiliza esa identificación para recuperar su archivo de sesión, que contiene su identificación de usuario.

Pensé en guardar el ID de sesión en una base de datos, vinculado al ID de usuario, y luego, cuando se inicializa la conexión de websocket, envío el ID de sesión de cookie y luego el servidor de websocket comprueba el ID enviado desde la base de datos.

Etapa dos

Si le gusta o comenta una publicación, necesita algún tipo de servicio que lo maneje, si le puede gustar o comentar, y qué hace cuando intenta hacer eso, y en mi opinión, esa lógica debería ser hecho en el servidor web, en el proyecto PHP.

Lo que pensé en hacer es enviar primero un XMLHttpRequest cuando te gusta o comentar una publicación, y esa solicitud devuelve el estado, si tiene éxito o no. Si tiene éxito, la respuesta contendrá el ID de la publicación o similar, y se enviará al servidor websocket, y el servidor notificará a todos los usuarios después de verificar que es real.

¿Puedes encontrar algún defecto en una de estas etapas? ¿Estoy pensando de la manera correcta?

php websocket

pregunta Ben Beri 20.07.2018 - 10:14

fuente

1 respuesta

Lea otras preguntas en las etiquetas php websocket

Omitir HSTS y la fijación de claves públicas con caracteres similares ¿Qué tan difícil es dirigir un correo electrónico a la carpeta de spam de un destinatario de Gmail? [cerrado]

score 1 · Answer 1

[...] si te puede gustar o comentar, y lo que hace cuando intentas hacer eso, y en mi opinión, esa lógica debería hacerse en el servidor web, en el proyecto PHP.

Oh, absolutamente. De lo contrario, implementaría las verificaciones en el lado del cliente, en cuyo caso la aplicación web decidirá si el usuario tiene permiso para comentar o recibir una publicación determinada. Puede hacerlo , pero también implementa verificaciones del lado del servidor. De lo contrario, nada me impide pretender ser otro usuario y enviar la solicitud directamente sin usar su aplicación web. Las verificaciones del lado del cliente nunca deben usarse como la única medida de seguridad.

También implementaría algún tipo de política de una conexión por usuario. En caso de que alguien robe / adivine el ID de sesión del usuario, él / ella puede establecer una conexión de socket web y tal vez incluso usar sus otros puntos finales (dependiendo de cómo se autentiquen). Este es un punto débil, ya que su conexión web se puede establecer (y se puede usar otro punto final) simplemente lanzando un ID de sesión válido en su servidor (¡independientemente del nombre de usuario / contraseña en su escenario!). Asegúrate de que las sesiones se agoten después de X minutos y que las ID de sesión sean mucho más difíciles de adivinar que las contraseñas (es decir, mediante una función criptográfica hash o un generador de números aleatorios seguro).

¿Permitir que solo un Websocket para cada ID de sesión (y solo una sesión activa por usuario?) evita que un atacante pueda secuestrar una sesión utilizada de forma desapercibida.

Como de costumbre, " no enrolle su propio criptografía " (si piensa en usarlo como software de producción). Como ya mencionó que "PHP obtiene los datos de usuario de la ID de sesión", asumo que está usando algún tipo de marco, ya que PHP no lo hace por sí solo. Quizás la funcionalidad de autenticación ya esté implementada.

tl;dr

Implemente todas las comprobaciones de seguridad al menos en el lado del servidor (el lado del cliente es Experiencia del usuario, no seguridad)
Asegúrese de que no sea factible adivinar los ID de sesión. Esto incluye sesiones de limpieza que ya no están en uso. Tal vez una política que aplique una sesión por usuario y una conexión de socket web por sesión si se ajusta a su caso de uso. Para que nadie pueda secuestrar una sesión inadvertida.