security - usando - sesiones php login
Seguridad de la sesiĆ³n de PHP (13)
php.ini
session.cookie_httponly = 1
change session name from default PHPSESSID
eq Apache agregar encabezado:
X-XSS-Protection 1
¿Cuáles son algunas pautas para mantener la seguridad de sesión responsable con PHP? ¡Hay información en toda la web y es hora de que todo llegue a un lugar!
Configuré mis sesiones de esta manera-
en la página de inicio de sesión:
$_SESSION[''fingerprint''] = md5($_SERVER[''HTTP_USER_AGENT''] . PHRASE . $_SERVER[''REMOTE_ADDR'']);
(frase definida en una página de configuración)
luego en el encabezado que se encuentra en el resto del sitio:
session_start();
if ($_SESSION[''fingerprint''] != md5($_SERVER[''HTTP_USER_AGENT''] . PHRASE . $_SERVER[''REMOTE_ADDR''])) {
session_destroy();
header(''Location: http://website login page/'');
exit();
}
Creo que uno de los principales problemas (que se está abordando en PHP 6) es register_globals.
En este momento, uno de los métodos estándar utilizados para evitar
register_globals
es usar los
$_REQUEST
,
$_GET
o
$_POST
.
La forma "correcta" de hacerlo (a partir de 5.2, aunque tiene un poco de buggy, pero estable a partir de 6, lo que vendrá pronto) es a través de filters .
Así que en lugar de:
$username = $_POST["username"];
tu harías:
$username = filter_input(INPUT_POST, ''username'', FILTER_SANITIZE_STRING);
o incluso simplemente:
$username = filter_input(INPUT_POST, ''username'');
Debe asegurarse de que los datos de la sesión estén seguros. Al mirar su php.ini o usar phpinfo () puede encontrar la configuración de su sesión. _session.save_path_ te dice dónde se guardan.
Compruebe el permiso de la carpeta y de sus padres. No debe ser público (/ tmp) o ser accesible por otros sitios web en su servidor compartido.
Suponiendo que todavía desea utilizar la sesión de php, puede configurar php para que use otra carpeta cambiando _session.save_path_ o guardar los datos en la base de datos cambiando _session.save_handler_.
Es posible que pueda configurar _session.save_path_ en su php.ini (algunos proveedores lo permiten) o para apache + mod_php, en un archivo .htaccess en la carpeta raíz de su sitio:
php_value session.save_path "/home/example.com/html/session"
.
También puede configurarlo en tiempo de ejecución con _session_save_path () _.
Consulte el tutorial de Chris Shiflett o Zend_Session_SaveHandler_DbTable para establecer un controlador de sesión alternativo.
El problema principal con las sesiones y la seguridad de PHP (además del secuestro de sesiones) se produce con el entorno en el que se encuentra. PHP almacena de forma predeterminada los datos de la sesión en un archivo en el directorio temporal del sistema operativo. Sin ningún pensamiento o planificación especial, este es un directorio legible para todo el mundo, por lo que toda la información de su sesión es pública para cualquier persona con acceso al servidor.
En cuanto a mantener sesiones sobre múltiples servidores. En ese momento, sería mejor cambiar PHP a sesiones manejadas por el usuario donde llama a las funciones proporcionadas a CRUD (crear, leer, actualizar, eliminar) los datos de la sesión. En ese punto, podría almacenar la información de la sesión en una base de datos o una solución similar a memcache para que todos los servidores de aplicaciones tengan acceso a los datos.
El almacenamiento de sus propias sesiones también puede ser ventajoso si está en un servidor compartido porque le permitirá almacenarlo en la base de datos, que a menudo tiene más control sobre el sistema de archivos.
Esto es bastante trivial y obvio, pero asegúrate de que session_destroy después de cada uso. Esto puede ser difícil de implementar si el usuario no cierra sesión explícitamente, por lo que se puede configurar un temporizador para hacer esto.
Aquí hay un buen tutorial sobre setTimer () y clearTimer ().
Hay un par de cosas que hacer para mantener su sesión segura:
- Utilice SSL cuando autentique usuarios o realice operaciones confidenciales.
- Vuelva a generar el ID de sesión cada vez que cambie el nivel de seguridad (como el inicio de sesión). Incluso puede volver a generar la ID de sesión cada solicitud si lo desea.
- Tener sesiones fuera de tiempo
- No uses registradores globales.
- Almacena los detalles de autenticación en el servidor. Es decir, no envíe detalles como el nombre de usuario en la cookie.
-
Compruebe el
$_SERVER[''HTTP_USER_AGENT'']
. Esto agrega una pequeña barrera al secuestro de sesiones. También puede consultar la dirección IP. Pero esto causa problemas para los usuarios que cambian de dirección IP debido al equilibrio de carga en múltiples conexiones de Internet, etc. (lo cual es el caso en nuestro entorno aquí). - Bloquee el acceso a las sesiones en el sistema de archivos o use el manejo de sesiones personalizado
- Para operaciones sensibles, considere la necesidad de iniciar sesión en los usuarios para volver a proporcionar los detalles de autenticación.
Me gustaría verificar tanto la IP como el agente de usuario para ver si cambian
if ($_SESSION[''user_agent''] != $_SERVER[''HTTP_USER_AGENT'']
|| $_SESSION[''user_ip''] != $_SERVER[''REMOTE_ADDR''])
{
//Something fishy is going on here?
}
Mis dos (o más) centavos:
- No confíes en nadie
- Entrada de filtro, salida de escape (la cookie, los datos de sesión también son su entrada)
- Evite XSS (mantenga su HTML bien formado, eche un vistazo a PHPTAL o HTMLPurifier )
- Defensa en profundidad
- No exponer datos
Hay un libro pequeño pero bueno sobre este tema: Seguridad PHP esencial por Chris Shiflett .
Seguridad de PHP esencial http://shiflett.org/images/essential-php-security-small.png
En la página de inicio del libro encontrará algunos ejemplos de códigos interesantes y capítulos de muestra.
Puede utilizar la técnica mencionada anteriormente (IP y UserAgent), que se describe aquí: Cómo evitar el robo de identidad
Si usa session_set_save_handler() puede configurar su propio controlador de sesión. Por ejemplo, podría almacenar sus sesiones en la base de datos. Consulte los comentarios de php.net para ver ejemplos de un controlador de sesión de base de datos.
Las sesiones de base de datos también son buenas si tiene varios servidores; de lo contrario, si está utilizando sesiones basadas en archivos, deberá asegurarse de que cada servidor web tenga acceso al mismo sistema de archivos para leer / escribir las sesiones.
Una de las pautas es llamar a session_regenerate_id cada vez que cambie el nivel de seguridad de una sesión. Esto ayuda a prevenir el secuestro de sesión.
Usar la dirección IP no es realmente la mejor idea en mi experiencia. Por ejemplo; mi oficina tiene dos direcciones IP que se utilizan dependiendo de la carga y constantemente nos encontramos con problemas al usar direcciones IP.
En su lugar, opté por almacenar las sesiones en una base de datos separada para los dominios en mis servidores. De esta manera, nadie en el sistema de archivos tiene acceso a la información de esa sesión. Esto fue realmente útil con phpBB antes de la versión 3.0 (ya han solucionado esto) pero creo que sigue siendo una buena idea.
Este papel de fijación de sesión tiene muy buenos punteros donde puede ocurrir un ataque. Véase también la página de fijación de sesión en Wikipedia .