2009-07-25 11 views
48

Tengo un script de inicio de sesión que verifica un nombre de usuario/contraseña con los datos en una tabla de 'usuario'. Además, tengo una tabla de "roles" que especifica el nivel de acceso de un usuario determinado. Suponiendo que estoy usando scripts de inicio de sesión seguros, ¿hay algún problema de seguridad al realizar una consulta adicional, al iniciar sesión con éxito, en la tabla de "roles" para descubrir el nivel de autorización del usuario y almacenarlo en una variable de sesión? La idea sería que en cualquier página con autoridad mixta, simplemente podría consultar la variable de sesión para descubrir el nivel de autorización del usuario conectado.¿Qué tan seguras son las variables de sesión de PHP?

Gracias.

Respuesta

69

Las sesiones son significativamente más seguras que, por ejemplo, las cookies. Pero aún es posible robar una sesión y, por lo tanto, el pirata informático tendrá acceso total a lo que esté en esa sesión. Algunas formas de evitar esto son la comprobación de IP (que funciona bastante bien, pero es muy baja fi y, por lo tanto, no es confiable por sí misma) y utiliza un nonce. Normalmente, con un nonce, tiene un "token" por página, de modo que cada página comprueba que el nonce de la última página coincide con lo que ha almacenado.

En cualquiera de los controles de seguridad, hay una pérdida de usabilidad. Si realiza la verificación de IP y el usuario está detrás de un firewall de intranet (o cualquier otra situación que lo cause) que no tenga una IP constante para ese usuario, deberá volver a autenticarse cada vez que pierda su IP. Con un nonce, obtienes la situación divertida de "Hacer clic atrás hará que esta página se rompa".

Pero con una cookie, un hacker puede robar la sesión simplemente mediante el uso de técnicas XSS bastante simples. Si almacena la ID de la sesión del usuario como una cookie, también son vulnerables a esto. Entonces, aunque la sesión solo es penetrable para alguien que puede hacer un hackeo a nivel de servidor (que requiere métodos mucho más sofisticados y, por lo general, cierta cantidad de privilegios, si su servidor es seguro), aún necesitará un nivel adicional de verificación sobre cada solicitud de script. No debe usar cookies y AJAX juntos, ya que esto hace que sea un poco más fácil ir a la ciudad si esa cookie es robada, ya que sus solicitudes de ajax pueden no obtener los controles de seguridad en cada solicitud. Por ejemplo, si la página usa un nonce, pero la página nunca se vuelve a cargar, el script solo puede verificar esa coincidencia. Y si la cookie contiene el método de autenticación, ahora puedo ir a la ciudad haciendo mi maldad utilizando la cookie robada y el agujero AJAX.

+19

Debe tenerse en cuenta que PHP almacena la identificación de la sesión como una cookie. –

+0

+1 ¿Podría explicar más sobre un nonce? posible enlace? – Petrogad

+5

El artículo de wiki sobre nonce es bastante ligero, pero tiene enlaces decentes: http://en.wikipedia.org/wiki/Cryptographic_nonce la idea básica, según tengo entendido, es como un token, pero solo se puede usar una vez (número utilizado una vez). Cada solicitud de página verifica la última pausa y crea una nueva. Entonces, si intento un ataque de fuerza bruta contra su contraseña, recibo una oportunidad, ya que el nonce no coincidirá en la ronda 2. Si robo la sesión y el tiempo de esa página, podría seguir haciendo solicitudes y renovando el contrato hasta usted hace una solicitud que arroja el fósforo nonce. Debido a que vería mi solicitud y mi nonce, actualice ... – Anthony

16

Solo los scripts que se ejecutan en su servidor tienen acceso a la matriz _SESSION. Si define el alcance de la cookie de sesión, incluso puede restringirla a un directorio específico. La única forma en que alguien además de ti podría obtener los datos de esa sesión es inyectando código PHP en una de tus páginas.

En cuanto al sistema que está utilizando, es aceptable y es una buena manera de guardar llamadas a la base de datos, pero tenga en cuenta que requerirá que el usuario cierre la sesión y vuelva a iniciar sesión para que se apliquen los cambios de autorización. Por lo tanto, si desea bloquear una cuenta y ese usuario ya inició sesión, no puede.

2

Si confía en un valor almacenado dentro de una variable de sesión para determinar los roles, pierde la capacidad de cambiar el valor en el DB y lo refleja en la sesión actual del usuario. Si observa Zend Framework, hay una clara distinción entre autenticación y autorización, y advertencias de gran redacción en el manual para almacenar solo la cantidad mínima de datos en la sesión (es decir, "Sí, es el usuario n. ° 37 & que inició sesión") .

En lo que respecta a la 'seguridad', a menos que esté en un host compartido, no hay de qué preocuparse. En un host compartido configurado correctamente, también deberían ser relativamente seguros.

13

Cabe destacar que en Apache se puede acceder a PHP $ _SESSION superglobal en todos los hosts virtuales.Considere este escenario:

  • Su servidor aloja dos dominios, ejemplo.com y instancia.org. Las sesiones de PHP se almacenan en cookies que están restringidas al dominio.
  • Un usuario inicia sesión en example.com y recibe una ID de sesión. Example.com establece algunas variables de sesión (que se almacenan en el servidor, no en la cookie).
  • Un tercero intercepta la cookie durante la transmisión y la pasa a instance.org. Instance.org ahora tiene acceso a las variables de sesión de example.com.

Esto no es tan importante cuando controlas todos los hosts virtuales en tu servidor, pero si estás en una máquina compartida, es problemático.

+1

¿sabes cómo restringir un sperglobal por host virtual, si es posible? – JRsz

+0

@JRsz puede cambiar el directorio donde se almacenan las sesiones en su php.ini ou a través de la función session_save_path() (http://php.net/manual/en/function.session-save-path.php). – SandroMarques

Cuestiones relacionadas