El equipo de desarrollo de Symfony acaba de publicar tres nuevas versiones de la rama 1.X para solucionar una vulnerabilidad de tipo SQL injection. El problema sólo afecta a la versión de Doctrine del generador de la parte de administración, por lo que el generador de Propel no está afectado por este problema.

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

Se acaba de publicar Symfony 1.2.6 para corregir un problema de seguridad detectado en todas las versiones de Symfony 1.2.X y 1.3.X tanto con Propel como con Doctrine. Por este motivo, se recomienda la actualización de todas las versiones afectadas.

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 seguridad es uno de los pilares de Symfony desde que en mayo de 2008 se modificó su política de seguridad tras un grave agujero de seguridad que tardó demasiado tiempo en corregirse. Hoy en día Symfony incluye numerosas estrategias y utilidades para hacer frente a los ataques XSS y CSRF.

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.

La semana pasada se publicó la versión 1.0.16 de Symfony, que corregía un grave error de seguridad. Aunque parezca increíble, la notificación sobre este error de seguridad se realizó hace más de un año. El ticket #1617 estuvo abierto durante más de 12 meses sin que nadie advirtiera sobre el grave peligro que suponía.

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

El MOPB sigue publicando fallos de seguridad de PHP (ya van 34 errores y la mayoría sin solución todavía) y Zend sigue con su táctica de publicar consejos breves y útiles sobre seguridad en PHP.

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