La importancia de la seguridad en Symfony
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.
Comentarios
-
#1
"grave vulnerabilidad descubierta en RubyOnRails."
de donde sacan esto?? esto no es una vulnerabilidad de rails y tampoco ha sido "descubierta", esto se sabe desde siempre porque asi fue disenado.
El "problema" es que AR es flexible y entonces el programador debe encargarse de explicitamente elegir que campos debe actualizar el formulario (si asi lo quiere)
"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."
entonces cual es la intencion de tanto FUD? en realidad, Symfony no presenta ninguna "gran" ventaja.
no entiendo como pueden escribir tanto FUD contra RoR y despues 2 parrafos mas abajo decir tranquilamente:
"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 fin...
RoR es un poco monolitico y sobrecargado a veces, pero Symfony es MUCHISIMO peor y este tipo de "mejoras" lo hacen aun mas monolitico.
-
#2
por cierto, Fabien dice que no hay solucion satisfactoria(mas FUD), pero esto es falso, dependiendo de lo que quieras hacer hay solucion, en mi caso extiendo dinamicamente la base de los modelos para 'settear' los campos que quiero cambiar, algo como:
def poner_atributos(nombres, params) nombres.each do |att| send("#{att}=", params[att] ) if params.has_key?(att) end end
y eso es mas que suficiente.
-
#3
Hola wtf???,
Respondiendo a tu pregunta sobre de dónde hemos sacado lo de "grave vulnerabilidad de RoR", te copio dos frases cortas del artículo del blog RailSpikes:
1) "In the case of ActiveRecord’s mass assignment vulnerability, the security issues are more servere and widespread than many of us recognize" 2) "Nearly every open source Rails application I’ve seen is vulnerable, and most closed source ones as well."
Así que la frase completa sería: "Según los expertos en RubyOnRails responsables del blog RailSpikes, se ha descubierto una grave vulnerabilidad en RoR"
-
#4
erm alli no dice que se ha descubierto, porque como ya lo dije, esto se sabe desde siempre, el mass assignment no es una vulnerabilidad, es una feature.
-
#5
wtf??? esta bien tener tu framework de eleccion, pero esta mal parcializar tus opiniones como un fanatico, eso no es objetivo y no es profesional, lo que dice javier es muy claro
-
#6
Bah, no hay necesidad de hacer mala fama a RubyOnRails, el sólito se la hace, sino preguntar a la gente de twitter porque tuvieron que migrar a PHP
-
#7
@daniel, como bien lo dices, NO HAY NECESIDAD. twitter no ha migrado a PHP y sigue usando RubyOnRails.
-
Los problemas de twitter no tienen nada que ver como ruby on rails como ya se explico en su blog el problema es que mysql no escala en un ambiente de mucha-escritura.
-
el framework o lenguaje es una herramienta, cuando te refieres a twitter tienes que hablar de twitter como aplicacion no de lo que use. las aplicaciones son las que escalan.
como puedes ver aqui http://rails100.pbwiki.com/Compete+Rankings hay una aplicacion rails que es la 42 mas visitada del mundo, muy por encima de twitter que es la 1426 (hoy)
- ruby on rails es MUCHO MAS rapido que symfony o CakePHP o Zend (http://www.avnetlabs.com/php/php-framework-comparison-benchmarks)
Cualquier persona que sepa un poco sobre escalar aplicaciones web sabe que las aplicaciones por si solas no escalan, necesitan ayuda de otros servidores, memcache, y un backend bien codificado
@ismael parece que no estas leyendo?
-
-
#8
oh por cierto, lo que hizo twitter fue reescribir el backend usando scala (http://www.scala-lang.org/) para la ui sigue usando rails
Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente
unos meses después de su publicación para asegurar que estos sigan
siendo relevantes.
Proyectos Symfony destacados
La plataforma de eCommerce 100% Symfony que rivaliza con Magento y PrestaShop. Ver más
Síguenos en @symfony_es para acceder a las últimas noticias.