plugin-development – Sesiones de WordPress y PHP: seguridad y rendimiento

Pregunta:

Estoy escribiendo un complemento de WordPress para tratar con una API de terceros.

Esta API requiere que se le pase un identificador de sesión para que la API (que básicamente funciona como un carrito de terceros) sepa qué elemento agregar y dónde; de ​​nuevo, piense en ello como un carrito.

Quiero almacenar este identificador de sesión en las sesiones de mis usuarios de WordPress. La idea sería conectarse a esta API, solicitar el identificador de sesión y luego almacenarlo en la sesión de WordPress / PHP para poder reutilizarlo mientras navegan por el sitio y agregar más elementos a su carrito de terceros. Reconozco que esto no es ideal (¿por qué no usar WooCommerce para hacer esto directamente?), Pero necesitamos algunas funciones y datos adicionales que solo este tercero puede proporcionar.

De todos modos, mientras intentaba hacer esto, encontré esto de nuestro anfitrión: https://wpengine.com/support/cookies-and-php-sessions/

Lo que confieso que encuentro terriblemente confuso.

De acuerdo con eso, las sesiones y funciones PHP como session_start() y session_id() no son recomendables, y no funcionarán en este host – … nuestro sistema ignora específicamente los encabezados que definen una cookie PHPSESSID.

Pero como señalan los documentos, SI LAS SESIONES DE PHP SON UN TIPO DE COOKIE, ¿CUÁL ES EL PROBLEMA?

En mi opinión, estos documentos no responden a esa pregunta.

Dice:

El mayor conflicto al usar sesiones PHP tiene que ver con los identificadores de sesión únicos. Debido a que la cadena de identificación de cada usuario es única, esto "elimina la memoria caché" con cada nuevo usuario que visita su sitio. ¡Este tipo de sistema no se escalará con muchos usuarios simultáneos del sitio! Con eso en mente, nuestro sistema ignora específicamente los encabezados que definen una cookie PHPSESSID.

Mi pregunta aquí es, ¿no es esto cierto para las sesiones que defienden, que se realizan simplemente a través de una cookie diferente que luego conduce a una conexión a la base de datos?

Dicen aquí:

¡La realidad es que hay una mejor manera de almacenar los datos de las sesiones de los usuarios! El método correcto es utilizar la base de datos para almacenar datos de la sesión. WooCommerce y otras soluciones de comercio electrónico ya se han convertido para usar este método en las sesiones PHP tradicionales, y también usan sus propias convenciones de nomenclatura de cookies.

Estos documentos continúan:

Más allá de las implicaciones de rendimiento y escalado, las sesiones PHP presentan otros problemas. De forma predeterminada, las sesiones PHP almacenan datos en el sistema de archivos como su propio archivo único. Escribir datos en un archivo es un proceso de E / S, y se sabe que este tipo de procesos hacen copias de seguridad y causan una alta carga en el servidor si su sitio recibe demasiados usuarios simultáneos. Sin mencionar que este tipo de almacenamiento de sesiones simplemente no funciona si su sitio está en una solución agrupada que abarca varios servidores web.

¿Por qué es esto peor / mejor que almacenar las sesiones en una base de datos? ¿No es eso también E / S?

Estoy tratando de entender: ¿por qué la sesión de PHP predeterminada se considera mala y la sesión de WooCommerce se considera buena? He examinado el código fuente de WooCommerce en las sesiones , pero no tengo la experiencia suficiente en este campo para descifrar por qué lo que están haciendo evita las vulnerabilidades como se menciona en los documentos del anfitrión.

Específicamente:

Existen múltiples vulnerabilidades de seguridad que se centran en las sesiones PHP. Las vulnerabilidades incluyen la exposición de los datos de la sesión, la fijación de la sesión y el secuestro de la sesión.

¿Cómo WooCommerce mitiga esto donde las sesiones de PHP no lo hacen? ¿Qué es recomendable para mi caso de uso?

Obviamente, no quiero sesiones inseguras, pero desarrollar una conexión de administrador de sesión / cookie / base de datos, como parece haber hecho Woo, tomaría algo de tiempo. Entonces estoy tratando de entender por qué / si es necesario replicar esto antes de invertir el tiempo en evitar las sesiones de PHP.

Respuesta:

Esto tiene muy poco que ver con wordpress, pero si esta respuesta ayuda a eliminar el uso de la sesión, podría valer la pena …

Las sesiones se almacenan en el disco duro del servidor. Esto es problemático en un escenario de alojamiento compartido porque el directorio de sesión probablemente sea legible y escribible por todos los procesos que se ejecutan en el servidor, no solo en su sitio. Todos los recursos compartidos en un servidor de alojamiento compartido que no tienen protección basada en el usuario a nivel del sistema operativo (como permisos de directorio) son al menos sospechosos y no debe usarlos para nada seguro o privado.

permite repetir Las sesiones se almacenan en el disco duro del servidor . ¿Qué sucede si está ejecutando en un entorno de varios servidores? ¿Cómo podrá localizar la información de su sesión? La única forma de que funcione es vincular a los usuarios a servidores específicos, lo que no es óptimo.

Y nuevamente las sesiones se almacenan en el disco duro del servidor . Si usa sesiones como parte integral de su generación de HTML, significa que no puede almacenar en caché su HTML.

WPEngine, es un alojamiento compartido en un entorno de múltiples servidores que realiza el almacenamiento en caché de forma predeterminada.

En cuanto a WC, como dijo en lo que está citando, no usan sesiones php e inventan su propio mecanismo almacenando información de sesión en la base de datos. Esta también es una solución problemática, ya que significa que el tráfico pesado podría hacer que el sitio caiga si no lo hace con sumo cuidado (supongo que en ese caso la sesión comienza solo cuando un usuario comienza el proceso de compra de un producto). Por qué lo hacen así y no dependen de las cookies, tendrá que preguntarles, supongo que el seguimiento de transacciones incompletas es parte de eso, otra parte es que la información de las cookies en los sitios http es básicamente pública, y si desea evitar fuga de información, es necesario almacenarla en el servidor.

¿Qué se aconseja en su caso? Esto será difícil de decir sin más detalles, pero probablemente debería trabajar para eliminar el uso de cualquier cosa que se sienta como una sesión. HTTP no fue diseñado para tener sesiones, y es mejor no luchar contra este hecho de la vida.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım