No, no deberías estar haciendo esto y no solo por ganancias mínimas de rendimiento. Me doy cuenta de lo que te hizo pensar que sería una buena práctica, pero analicemos un poco más estas dos citas del manual de PHP:
session_start() crea una sesión o reanuda la sesión actual basada
en un identificador de sesión pasado a través de una solicitud GET o POST, o pasado
a través de una cookie.
session_destroy() destruye todos los datos asociados con el
sesión actual. No anula ninguna de las variables globales.
asociado a la sesión, o desactive la cookie de sesión. Usar el
las variables de sesión nuevamente, session_start () debe ser llamada.
Está bien, eso está claro. También menciona en su publicación en SO que existe la posibilidad de que el usuario pueda navegar directamente a este URI desde donde ejecutará este código. Realmente no debería hacer esto y al menos debe verificar los datos de inicio de sesión del usuario y la cadena de referencia antes de iniciar la sesión y eliminar la sesión cada vez que cambie el estado del usuario. Pero digamos que no cambió su código y podemos navegar al URI en cuestión. Ahora imagine este escenario:
- Tengo acceso a una de las computadoras de su usuario legítimo, su red, puedo acceder a su aplicación web a través de la misma IP y puedo recopilar sus datos de sesión del lado del cliente
- Realizo una solicitud POST o GET sin datos de sesión a su URI que ejecuta este código
- Agrego manualmente estos fragmentos de sesión (cookie de sesión, cadena de usuario-agente) a los que tengo acceso en mi navegador modificado
Voila!
Todo esto es realmente fácil de hacer y muchas personas con acceso directo a la computadora del usuario específico tendrían los medios y las razones para hacer tal cosa, si solo tuvieran conocimiento de ello. Y estás bajando ligeramente esa barra.
Veamos qué pasará.
Se llamará a
session_start() antes de que la sesión se invalide en su servidor web (lo que ocurre en session_destroy() ), creando una nueva sesión de usuario. Luego puedo reemplazar los datos de mi nueva sesión con el antiguo (robado), y su aplicación web tendrá (según los datos de mi sesión de usuario final) ninguna razón para sospechar que no soy el usuario para el que se creó la sesión la primera vez. lugar. Se reanudará como si fuera el usuario anterior al que robé los datos de la sesión.
Entonces, ¿en qué se diferencia esto del secuestro de sesión cuando se utilizan las rutinas de manejo de sesión en el orden previsto?
En una larga discusión con @Xander que disecciona las rutinas de manejo de sesiones de PHP, hemos llegado a la conclusión de que no cambia nada en ese sentido. Sin embargo, tampoco gana nada haciéndolo, y podría resultar en una ruptura de la funcionalidad de cualquier marco de sesión de usuario de terceros, si su aplicación PHP depende de. Comentando su pregunta SO relacionada "Me preocupa que si un el usuario navega directamente a esta página puede haber un error al destruir la sesión " expone otra preocupación, es que básicamente está permitiendo que el explotador vea su estructura de datos de sesión de usuario final de forma gratuita, sin ninguna autenticación de usuario antes de crear eso. Decir "¡Pero lo estoy eliminando inmediatamente!" realmente no se aplica en este sentido, ya que session_destroy() "... no anula ninguna de las variables globales asociadas con la sesión , o desactive la cookie de sesión. " Diciéndolo de manera diferente:
¡Acabas de hacer el secuestro de sesiones un poco más fácil, no al revés!
TL; DR : en resumen, tendrá que hacerlo 'la forma aburrida y estándar' , ya que está en el orden en que se realizaron estas dos rutinas de cambio de sesión. diseñado para funcionar.