Etiqueta: Configuración

  • Cómo definir la configuración de la sesión en Symfony

    Cómo definir la configuración de la sesión en Symfony

     

    Ante todo, una aclaración:

    PHP maneja las sesiones a través de cookies (Antiguamente también se podía propagar el ID de sesión vía URL, aunque es una práctica muy poco segura y, sinceramente, hace mucho que no lo veo).

    Bien, ahora… ¿qué cosas podrías querer cambiar de la configuración de la sesión? Varias.

    1. El nombre de la cookie
    2. El tiempo de duración
    3. El lugar donde se almacena la información del lado del servidor

    Sobre la segunda y la tercera, acá tenés un ejemplo de por qué querrías hacerlo 🙂

    Respecto de la primera, más que nada se trata de un tema de seguridad. Fijate esta captura de pantalla de la consola del navegador:

    El nombre PHPSESSID es el nombre por defecto que se le asigna a la cookie de sesión de una aplicación hecha en PHP, eso significa que, si te encontrás con una cookie con este nombre es altamente probable (Por no decir seguro) que del otro lado se encuentre una aplicación desarrollada en PHP.

    Ese tipo de información es super útil para un atacante, ya que al conocer qué software está corriendo el servidor se le facilita enormemente la tarea de buscar una forma de explotarlo…

    Bien, ahora que te convencí de que es una buena idea cambiar el nombre de la cookie, te voy a mostrar cómo hacerlo en Symfony:

    Es muy simple, se trata de agregar un par de líneas al archivo config.yml:

    framework:
        session:
            # http://symfony.com/doc/current/reference/configuration/framework.html#handler-id
            handler_id:  session.handler.native_file
            save_path:   "%kernel.root_dir%/../var/sessions/%kernel.environment%"
            cookie_lifetime: 28800
            name: MIAPPSID

    Se puede configurar todos los parámetros de la sesión mediante este mecanismo y después, por ejemplo, se puede modificar algunos valores para el entorno de desarrollo definiendo un archivo config_dev.yml con algo como:

    imports:
        - { resource: config.yml }
    
    framework:
        session:
            save_path:   "/var/lib/php/sessions"

    Listo. Ahora tu aplicación es un poco menos vulnerable que antes :).

    P.D.: Si querés incorporar un framework maduro como Symfony a tu herramental, el curso Desarrollo de Aplicaciones Web Profesionales con PHP te puede interesar.

  • Cómo alterar la configuración de PHP sin acceder al php.ini

    Cómo alterar la configuración de PHP sin acceder al php.ini

    En el servidor no tengo acceso a php.ini (alojamiento gratuito) por lo que debo configurar los cambios a través de “.htaccess”.

    La configuración estándar de PHP no siempre es la adecuada para nuestras aplicaciones (Por ejemplo, la cantidad de memoria permitida para un script o el tiempo máximo de ejecución).

    Desafortunadamente, no siempre podemos hacerlo del modo normal, es decir, modificando el archivo php.ini.

    Es más, existen casos en los que no querremos que estos cambios tengan efecto en scripts diferentes del que estamos desarrollando.

    El típico caso en que esto sucede es un entorno de hosting compartido.

    Algunos proveedores dan acceso a una versión particular del archivo por cada sitio que alojan, aunque la mayoría no lo permiten en absoluto (Es lógico si se piensa un poco, un servidor en el que corren muchas aplicaciones debe hacer un gran esfuerzo por evitar que un vecino poco solidario acapare los recursos del sistema o lo vuevla inestable).

    En estas situaciones, algo que podemos hacer es utilizar la función ini_set.

    Esta función permite alterar algún parámetro de la configuración por espacio del hilo de ejecución actual (Es decir, el cambio no tendrá efecto en otros scripts que se estén ejecutando simultáneamente ni una vez finalizada la ejecución en curso).

    Algunos ejemplos interesantes:

    Parámetros de sesión

    La directiva session.name especifica el nombre de la cookie de sesión que usará nuestra aplicación. Es muy importante ponerle un nombre único para evitar dar a un potencial atacante información que facilitaría su tarea (Por ejemplo, al dejar el nombre por defecto, PHPSESSION, el agresor ya sabe que nuestra aplicación está desarrollada en PHP)

    Zona horaria

    Algo muy útil cuando se trabaja con usuarios de diferentes lugares del mundo (O cuando el hosting está en una zona horaria diferente de la del usuario) y se requiere hacer cálculos de fecha/hora. Más detalles acá.

    Remitente de correos por defecto

    La directiva sendmail_from permite definir la dirección de email desde la que se enviarán los correos de nuestro script.

    Una aclaración importante: no todas las directivas de PHP pueden modificarse usando esta función.

    Acá está la lista completa.

  • Dónde almacenar la configuración de una aplicación PHP de forma segura

    Dónde almacenar la configuración de una aplicación PHP de forma segura

    Una pregunta que me llegó de un amigo que viene del mundo .Net (Que parece ser un poco más organizado o estandarizado que el nuestro :).

    Lo primero que deberíamos preguntarnos es de qué nos estamos queriendo proteger.

    Por lo general, la posibilidad de que alguien externo a nuestra organización tenga acceso a la configuración de nuestra aplicación no parece muy tentadora… ¿por qué? Básicamente porque puede haber información sensible (Como ser contraseñas, nombres de hosts donde están las bases de datos, etc…) que podrían dar a un atacante una ventaja importante si decidiera hacernos un daño.

    Una línea de defensa que tenemos es guardar estos archivos en un directorio que no sea públicamente accesible.

    Si usás el webserver Apache, conocerás seguramente la directiva DocumentRoot: lo que está «a la vista» de los visitantes es exclusivamente lo que está dentro de ese directorio (O subdirectorios, según cómo esté configurado el servidor), pero (y esta es la parte interesante), no es lo único que está a la vista para un script php.

    Ejemplo:

    <VirtualHost *:80>
     ServerName my.domain.com
     ServerAdmin webmaster@localhost
     DocumentRoot /usr/share/apache2/mysite
    
     <Directory /usr/share/apache2/mysite>
      Options FollowSymLinks
      AllowOverride All
     </Directory>
    </VirtualHost>

    Con esta configuración, cuando yo ingrese a la URL http://my.domain.com/index.php, el servidor me dará el HTML generado por la ejecución del archivo /usr/share/apache2/mysite/index.php.

    Imaginemos que index.php tiene algo como esto:

    <?php 
    
    require_once '../config.php';
    echo 'Hola Mundo!';

    Si yo intentara entrar (desde mi browser) al archivo config.php debería escribir algo como http://my.domain.com/../config.php (Eso obviamente, sabiendo que ahí se encuentra el archivo que busco).

    Si bien podría llegar a pasar que el webserver esté mal configurado y permita hacer eso, en la gran mayoría de los casos, eso simplemente será imposible (Los requests están confinados a leer archivos que están dentro del DocumentRoot).

    Si estás usando un framework estándar (Symfony, CakePHP, Laravel, etc…), esto ya estará previsto (Habrá un directorio especial para almacenar los archivos de configuración, pero siempre en última instancia se va a tratar de un tema de permisos configurados a nivel de webserver).

    ¿Conocés alguna otra forma de proteger tus archivos de configuración? ¡Compartila en los comentarios!