¿Estas dos formas son seguras?

Question

¿Estas dos formas son seguras?

#1 de rook (2 votos)
#2 de Eric G (1 votos)

2

Tengo dos escenarios y quiero saber si cada uno es seguro o qué riesgo existe.

Número uno:

Si el usuario tiene el enlace de edición (editar / [md5hash]) puede editar una publicación. La tecla de edición (el hash) está en un campo de formulario oculto para indicar a la Acción del Controlador qué publicación se editará.

El usuario podría editar el valor de ese campo, pero necesitaría otras claves para cambiar otras publicaciones, ¿verdad?

Número dos:

Cuando el usuario crea una publicación. Se establece una cookie con el nombre "post [id]" y el md5-edit-hash como valor.

Cuando se solicita una publicación, el controlador comprueba si el hash de edición en esa cookie (si existe) es el mismo que en los datos de la publicación.

No es seguro que muchas personas compartan el navegador y las cookies no se reinician, ¿no es así? ¿Hay otros problemas o soluciones para hacerlo más seguro y mejor?

Gracias

Editar:

Estoy usando Laravel 3 - un PHP Framwork Sí, estoy evitando la autenticación por razones especiales;)

Podría usar cualquier otro método hash como SHA, si esto fuera un problema

El hash se genera a partir de una marca de tiempo + salt + postid + salt + authorname

cookies php

pregunta Strernd 02.05.2013 - 00:44

fuente

2 respuestas

Lea otras preguntas en las etiquetas cookies php

¿Existe un complemento de Skype que use TLS y ZRTP? Riesgos del acceso a Microsoft Remote Desktop detrás de una VPN segura

score 2 · Answer 1

No veo ninguna semejanza con el control de acceso en ninguno de los dos escenarios. Si aún no te han dicho esto: deja de usar md5! es antiguo, está roto y es ineficiente, usa SHA-256 o simplemente un nonce criptográfico .

En el primer escenario, si el atacante conoce este "md5hash" mágico, entonces podrá usar esta función de edición siempre. ¿Cómo evitas que el usuario obtenga este hash? ¿Cómo se genera este hash?

El segundo escenario parece aún menos seguro, es trivial enviar una variable de publicación y cookie arbitraria:

curl http://some_vulnerable_site.com/edit  --data "post[id]=1&hash=somevalue" --cookie "hash=somevalue"

Todos los valores de encabezado GET, POST, COOKIE y HTTP están bajo el control de los atacantes. Una cookie debe contener un ID de sesión, que hace referencia al estado de ese usuario (un ID de usuario), que se puede utilizar para imponer el control de acceso a los datos.

Si desea obtener más información sobre seguridad, asegúrese de leer el OWASP top 10 . En cuanto a esta publicación, debe leer: OWASP A3- Autenticación rota y gestión de sesión .

score 1 · Answer 2

Estás implicando seguridad por oscuridad. Es decir, este es un número aleatorio grande que no podría adivinarse fácilmente, y podría llevar algún tiempo pasar la fuerza bruta. Sin embargo, como está haciendo un hash de un valor, el valor md5 se vuelve más predecible, quizás vinculado a algunas variables conocidas. El aumento de aleatoriedad es mejor, pero pierde el punto.

Estos tipos de valores a veces se usan para restablecimientos de correo electrónico, tickets de soporte, etc. Cuando se usan de esta manera, deben tener una restricción de tiempo o acceso de solo lectura. Si está pasando por HTTPS, sería más difícil, pero no improbable que un atacante obtenga este valor mágico (MiTM, ataque de loca, ataques de predicción, etc.).

Si no desea implementar un sistema de autenticación completo, es posible que desee considerar un hash aleatorio + algún tipo de pin por publicación. Si el pin no se basa en el hash, entonces esto es de alguna manera una contraseña por página / edición. Sin embargo, aún tiene muchas consideraciones y le aconsejaría que no cree su sistema de autenticación. Si lo haces mal, puedes terminar exponiendo las credenciales o hacerlas fácilmente anuladas.

El hecho de que tenga autenticación no significa que deba hacer una verificación por correo electrónico, etc. Parece que quizás le preocupa que sus usuarios no quieran ser rastreados o hacer un esfuerzo por configurar una cuenta, y eso si Tenían que pasar por toda la autenticación, solo usarían otro servicio. Puede realizar la autenticación como lo hacen en hacker news , donde solo crea una cuenta con una contraseña y no está vinculada al correo electrónico.

A largo plazo, recomendaría aumentar la propuesta de valor de su sitio web para que los usuarios quieran usar autenticación real. Si es una cuestión de privacidad, permítales usar las cuentas de correo electrónico desechables o ninguna cuenta de correo electrónico. Incluso sin cuentas, es trivial hacer un seguimiento de usuarios individuales en un sitio web.