El problema de seguridad en php 5.3.0, se que actualmente la versión estable de php es 5.3.1 pero estuve observando el changelog y no encontré ningún indicio de haber encontrado y reparado este problema que quiero contar.
El problema es que si inicias sesión con session_start() te crea una cookie llamada "PHPSESSID" la cual contiene un valor alfanumérico y el problema está en que si modificas el valor de dicha cookie una ves creada la sesión entonces se creará un nuevo archivo en el directorio temporal con el nombre de la cookie.
Yo entiendo que el valor máximo de carácteres de un archivo son 256 por lo tanto si le ponemos un valor al PHPSESSID de 300 carácteres se producirá un error revelando un "path disclosure" pudiendo forzar cualquier resultado.
Ejemplo:
Código
<?php if($_SESSION) echo $_SESSION; else $_SESSION = 'xx'; ?>
Ahora envías la petición con tu cookie modificada:
Código
<?php $payload = 'GET / HTTP/1.1 Host: 127.0.0.1 Connection: close '; }else{ } } ?>
Resultado:
Citar
Warning: session_start() [function.session-start]: open(/tmp/sess_aaaaaaaaaaaaaaaaaa ..... aa in /opt/lampp/htdocs/test.php on line 3
Al enviar esto por correo me dijeron lo siguiente:
Citar
No del todo seguro de haber entendido. ¿Es sólo una ruta de divulgación del mensaje de error le preocupa? Nosotros no consideramos que un problema de seguridad porque los sistemas de producción no debe estar funcionando con "display_errors" activada.
-Rasmus
-Rasmus
Y bueno, como vi que no les interesaba mucho le dije que ya no lo molestaría mas:
Citar
Si, es lo ideal, y también todos deberían urilizar htmlspecialchars para evitar xss y mysql escape real string para evitar una inyección sql pero no todos lo hacen.
Actualmente a grán mayoría de sistemas CMS contienen en sus configuraciones un error_reporting habilitado tales como joomla, wordpress, phpbb, vbulettin, smf, moodle, phpnuke, phpmyadmin, sqliteadmin, y muchos mas.
recuerdo hace un tiempo pasado hubo un problema debido a que la cookie de sesión permitía carácteres que no fueran alfanuméricos y por la misma razón se producía el mismo tipo de error lanzando un "path disclosure", por lo cual supuse que también podría importarles pero veo que me equiboqué, no volveré a molestarlos.
Actualmente a grán mayoría de sistemas CMS contienen en sus configuraciones un error_reporting habilitado tales como joomla, wordpress, phpbb, vbulettin, smf, moodle, phpnuke, phpmyadmin, sqliteadmin, y muchos mas.
recuerdo hace un tiempo pasado hubo un problema debido a que la cookie de sesión permitía carácteres que no fueran alfanuméricos y por la misma razón se producía el mismo tipo de error lanzando un "path disclosure", por lo cual supuse que también podría importarles pero veo que me equiboqué, no volveré a molestarlos.
Probé este bug en varios servidores y comunidades muy conocidas y de los 8 servidores solo dos no reaccionaron a este problema debido a que por defecto en la configuración del servidor impiden la visualización de errores pero en todos los demás funciona bién.
Incluso puedes crear un exploit para resolver la ruta local del archivo afectado que utilize sesiones de php con session_start().