:::: MENU ::::

Cookies VS Session en PHP

Si eres programador de PHP sabrás que existen cookies y session, y, seguramente, habrás usado ambas.
Para hacer una web “tonta”, o de prueba, o en la que simplemente te vayas a loggear tu y no la conozca nadie y no tengas nada interesante, ¿para qué usar cookies si es mucho más tedioso?
Pero bueno, quiero hacer este post para discutir sus ventajas, desventajas, etc.

Session
Las sesiones de PHP es un sistema que lleva incluido el cual crea una cookie en el navegador llamada PHPSESSID que contiene un código de 32 caracteres generados al azar, y luego crea una carpeta donde para cada sesión guarda un archivo que contiene todos los parámetros que guardes en los conocidos $_SESSION[‘algo’].
Sí, es tan cómodo como poner session_start(); y empezar a guardar datos en el usuario, y para desloguearle es tan sencillo como un simple session_destroy();.La cosa es que también podemos intentar robar sesiones a base de fuerza bruta u obteniendo la cookie del navegador (pero lo último es algo irremediable, si tenemos acceso al ordenador del usuario, da igual si son cookies, sesiones, etc. que si queremos robar la sesión, podemos). Incluso con un analizador de de protocolo de red podemos sacar las cookies muchas veces, si no entran con SSL está chupado, y si no tan fácil como usar nuestra amiga, la foquita malvada, y hacer un SLAAC attack, pero bueno, olvidemos eso peusto que pasa lo mismo con las cookies.

Cookies
Volviendo al debate entre Cookies y Session (puesto que en la anterior me he ido por los cerros de Úbeda hablándoos de la Foca), las Cookies nos ofrecen más posibilidades a los programadores para jugar. Básicamente podemos crear cookies de la duración que queramos, con el nombre que queramos, que funcionen en la carpeta que queramos y encima los que almacenan la información temporal son los usuarios y no nosotros. Aun así, no es recomendable leer la información de las cookies y basarse en ella. Si es algo que el usuario pueda editar desde la web (como por ejemplo, el primer paso de un registro de dos pasos, siempre verificando la información dada), entonces sí que podemos confiar en que si editan algo, no nos perjudicará, ya que como buenos programadores comprobaremos que todo lo almacenado en las cookies sea válido como en el confirmación del primer paso del registro ¿verdad? (si no ya sabéis, ahí tenéis unas vulnerabilidades que arreglar YA).
Una vez sabemos los fundamentos de las cookies, sabemos que si almacenamos el ID de un usuario pueden simplemente cambiarlo por otro ID, y así entrar por ejemplo en el ID 1 que será seguramente el creador/administrador de la web. Pero para solucionar eso lo que se hace es crear otra cookie con números, letras, otros caracteres o lo que sea generados al azar y muy largos (de 100 o más caracteres) y almacenarlos junto al usuario en la base de datos, de modo que si el ID y el código creado coincide con las cookies se permite que vea la web logueado. Y sí, con eso también se puede hacer fuerza bruta, pero a más caracteres, más seguridad y además nos permite a los programadores tener el sistema de seguridad que queramos.
La cosa de las cookies es que podemos personalizar la duración, le podemos dar algunos flags que “aumentan la seguridad”, poner la ruta que queramos, y en fin, tenemos más control sobre las sesiones, y al fin y al cabo, cada programador tiene su estilo.

En definitiva: yo opto por usar cookies, siempre que vayamos con cuidado, aun que me niego rotundamente a poner el cartelito de ‘esta web usa cookies’, es una obviedad que si te vas a loguear por narices vas a usar cookies, dudo que haya alguna web que con el navegador, el sistema operativo y la IP ya te permita loguearte, por que si no tu herman@, padre, madre o lo que sea con el mismo ordenador vería tu cuenta, con lo cual, cookies always, ya sea por la sesión del PHP que crea una sola cookie, o por las cookies que cree una página personalizadas.

Y por último quiero pedir disculpas por haber estado tanto tiempo sin escribir nada, la verdad es que el tiempo no es algo que abunde, sobretodo cuando tienes pendientes 20mil trabajos de programación y 10 personas pidiéndote cada día por Skype cómo los llevas ejem. Y también os recuerdo que en mi canal estoy subiendo una serie de Minecraft (que no tiene nada que ver con informática, pero en mi canal hago lo que me da la gana, ¿no?) así que ya sabéis, si os gusta, ahí está :P

Buenas tardes y feliz fin de semana a todos :D


Easter Egg de PHP, un peligro a tener en cuenta

Como ya sabréis, los Easter Egg son bromas que incluyen algunas compañías de Software en sus productos para reirse un rato. Obviamente, si vemos un Easter Egg en un juego no va a pasar nada, hay Easter Eggs en la mayoría de juegos, e incluso en sitios web, por ejemplo en Google o Youtube (haciéndo click los veréis). Incluso hay algunos más currados en videojuegos que han interferido en la vida real, por ejemplo este Easter Egg de Trials explicado por Alexelcapo, el cual, personalmente, me emocionó.

Una vez sabemos lo que son los Easter Eggs, vamos a ver en que afecta a PHP. PHP posée un easter egg en el cual si entras en una página web (que use php) con este GET: ‘?=PHPE9568F36-D428-11d2-A769-00AA001ACF42‘ podremos apreciar una imágen (hay más Easter Eggs, pero no los indicaré aquí). Lo primero que nos dice esta imagen es que usamos PHP, y lo segundo es la verisón, puesto que cada par de versioens PHP cambia la imagen según el esquema que tenemos aquí abajo:

Tabla de versiones e Easter Eggs.

Tabla de versiones e Easter Eggs.

¿En qué nos perjudica esto?
Al saber nuestra versión de PHP, el atacante puede buscar vulnerabilidades de dicha versión y utilizarlas en nuestra contra, por ello es recomendable desactivar el Easter Egg (como indicaré aquí abajo) y además conviene actualizar siempre a la última versión. Además, en este artículo de Detectify podrás encontrar listas de vulnerabilidades para cada ‘imagen’ proporcionadas por CVE.
Además apareceremos como vulnerables en la mayoría de escáneres de pentesting, podemos ver un ejemplo del mismo Detectify aquí abajo.

Detectados por Detectify

Detectados por Detectify

¿Cómo lo desactivo, entonces?
Muy fácil, solo tenemos que poner a ‘Off’ el parámetro ‘php_expose’ del archivo de configuración de PHP, conocido como php.ini.

Además
Con eso también desactivas el ‘X-Powered-By’ de PHP, que es un header que envía PHP al procesar la página en el cual se indica su versión.

X-Powered-By

Header X-Powered-By

Disfrutad del fin de semana :D