2010-03-15 16 views

Respuesta

16

Los datos de la sesión se almacenan en el servidor. Solo la identificación de la sesión se transfiere entre el cliente y el servidor. A menos que una secuencia de comandos del lado del servidor se equivoque (o haya un error), el cliente no puede cambiar los datos de la sesión directamente. Pero debe asegurarse de que solo el cliente "correcto" conozca la identificación de la sesión, ya que vincula a este cliente en particular con una sesión en particular. P.ej. (ya que mencionó un inicio de sesión) use session_regenerate_id() siempre que se realice un inicio de sesión (intento) para prevenir session fixation

4

Sí .. Se llama sesión forge/hijack.

Cambia el valor de la cookie de sesión hasta que obtiene otra sesión de usuario.

+2

+1 para señalar el secuestro de la sesión, pero debo agregar que no cambia la variable en el servidor. Puede permitir que un usuario pose para otro. La seguridad/probabilidad de esto depende de la complejidad de sus ID de sesión y de por cuánto tiempo son válidos. – deceze

+0

Debido a la segunda parte de la pregunta del OP, creo que esta respuesta responde mejor a la intención general de la pregunta. – overslacked

+0

por simplicidad. digamos que tengo if ($ _ SESSION ['userName'] == "admin) {// cosas para el administrador} else {// cosa para el resto} ¿Es una manera de forjar/secuestrar la variable de sesión userName? ¿Por qué? nadie habla de esto ?? –

7

Las sesiones se almacenan en su servidor, ya sea en un archivo o en la memoria. El usuario solo tiene una cookie que define la ruta (generalmente un hash de alguna forma) a los datos de la sesión en su servidor. Teóricamente, podría cambiar la cookie al hash de otra persona, pero eso es muy, muy improbable, a menos que los almacene como archivos y no los elimine después de que caduquen, en cuyo caso la probabilidad de que alguien explote una sesión anterior aumentaría.

+0

Muy, muy improbable, cuando se aplica sobre miles de millones de transacciones, puede convertirse fácilmente en algo que valga la pena preocuparse bastante. Por supuesto, no tengo idea de la escala del proyecto del OP, pero es algo a considerar. – overslacked

0

Para evitar almacenar datos de sesión en el servidor, puede sign proteger el contenido que desea proteger del cambio, antes de almacenarlo en la sesión, y luego validar justo después de la recuperación de la sesión. En PHP, este proceso es reasonable simple y elimina los problemas de almacenamiento del servidor.

Tenga en cuenta que esto no protege la visualización de datos de sesión. Si necesita esta protección, aún puede evitar el almacenamiento del servidor mediante el uso de cifrado seguro. Solo tenga en cuenta que prácticamente todos los esquemas de cifrado basados ​​en el tamaño de la clave se pueden romper en el futuro cercano. Entonces, si necesita proteger sus datos de sesión por ejemplo, 5 años, la elección segura de la clave y el algoritmo puede crear problemas de rendimiento.

Cuestiones relacionadas