Según CAST research labs, los framework opensource Java son un riesgo de seguridad
Abraham
CAST research labs ha publicado un informe titulado "CAST Report on Application Software Health" donde analiza la seguridad de aplicaciones empresariales. En el análisis se han incluido 496 aplicaciones que en total suponen 152 millones de líneas de código. Las aplicaciones pertenecían a 88 organizaciones diferentes.
Una de las conclusiones de este informe es que desde el punto de vista de la seguridad los framework open source de Java son un riesgo y pueden hacer que nuestros datos no estén seguros. Según este análisis, la calidad de los diferentes frameworks opensource presenta una variabilidad bastante alta. Por ejemplo, Hibernate según su análisis ha demostrado ser excelente en cuanto a temas de seguridad. Pero Struts ha resultado ser nefasto.
No obstante, en la mayor parte de los casos el problema de seguridad ocasionado por el framework no se debe realmente al propio framework, sino a un uso inadecuado de este a través de una configuración errónea por parte de los desarrolladores.
Otras conclusiones curiosas del estudio es que las aplicaciones Java EE que no empleaban ningún framework han demostrado tener los índices de calidad más altos. Las aplicaciones que mezclaban Java con C o C++ se encuentran entre las que tienen índices de calidad más bajos. Sin embargo las que empleaban Java y COBOL o .NET tenían índices de calidad altos.
La verdad es que alguna de las conclusiones de este informe parecen un tanto arbitrarias (mezclar Java con C disminuye la calidad, pero con COBOL la incrementa). Así que yo me tomaría con cuidado sus conclusiones. A pesar de que la muestra del análisis es grande (152 millones de líneas de código), al final sólo se han analizado 88 organizaciones.
Sin embargo, un dato que parece interesante y probablemente sea cierto, es que probablemente muchas aplicaciones que emplean frameworks opensource tienen problemas de seguridad derivados de una mala configuración del framework. Este punto es consistente con mi experiencia ¿lo es también con la vuestra?
Reader Comments (7)
Creo que esto es una navaja de doble filo:
Por una parte, un framework que es usado, matenido, testeado por mucha gente, seguramente sea mucho más seguro, ya que se estará corrigiendo y actualizando concretamente. Pero por lo mismo ciertas versiones del framework pueden tener ciertas vulnerabilidades conocidas y fácilmente explotables, que si no nos preocupamos de actualizar el framework, nuestras aplicaciones se pueden ver expuestas. También, al tener accesible el código fuente, es probable, que en cierta medida estemos facilitando el descubrir nuevos errores a gente con mala intención. Pero es mucho más probable que alguien, trasteando con el código y el framework pueda sacar alguna vulnerabilidad, aunque al estar utilizado por mucha gente, estas probablidades disminuyen con forme más gente usa el framework.
Por otra parte, si no usamos un framework, y el software es cerrado nos exponemos a cometer muchos errores que no han sido ampliamente comprobados y dejar la puerta abierta a una gran variedad de posibles ataques, al no haber tenido en cuenta multitud de cosas. También, al no utilizar una tecnología conocida, es más complicado explotar alguna vulnerabilidad en concreto, pero si que es mucho más probable que tengas muchos agujeros de seguridad abiertos.
No se el informe, por lo que parece puesto que no me voy a registrar para acceder, pero las conclusiones y el artículo en ZDNet son un total desproposito. No merece ni darle crédito comentándolo.
He vuelto a recordar a Winston Churchill y sus opiniones sobre las estadísticas:
"Existen mentiras, grandes mentiras y estadísticas"
"Las únicas estadísticas en las que creo son las que hago yo mismo"
Si se cambia "estadísticas" por "informes"... ¡Igual servirían tal cual!
Yo estoy de acuerdo con el informe, porque no dice que los frameworks sean malos, si no que estan mal configurados...
Al arrancar un proyecto se dice "vamos a usar Spring, Hibernate, JSF, Quartz, etc" y las personas que lo hacen aprenden sobre la marcha, porque nadie puede hacerse un experto en un framework en un mes, y mucho menos en una docena de frameworks. Ademas, el que haya tantos ejemplo en San Google ayuda mucho cuando tienes que entregar antes del viernes, porque copias un trozo de codigo y funciona, y pasa las pruebas, pero una cosa es que funcione y otra es que sea lo correcto para tu caso en concreto. El ejemplo de internet ¿evaluaba todos los codigos de retorno? ¿Las excepciones? ¿El que lo colgo lo puso todo o simplifico el ejemplo para que se entendiera?
Y la diferencia en cuanto a las mezclas de lenguaje, yo creo que tendra mas que ver con el perfil de la gente que con los elnguajes en si. La gente que programa en Cobol suele tener canas y muchas tablas ya, mientras que todo el mundo sabe programar en C porque lo ha dado en la universidad. El problema de la mezcla con C seguramente venga porque otra cosa es programar BIEN en C, que una cagada con GC se nota menos, y un error en un puntero en Java es una NullPointerException y en C es un core. Lo que si me sorprende es que la mezcla entre Java y .Net sea buena, porque los considero mas o menos equivalentes y supongo que sera la misma clase de gente...
Vamos, que el estudio me resulta creible porque lo que importa es la gente, y si cada año esta cambiando de framework no puede ser experta.
Cualquier aplicación en C/C++ se ejecuta en un entorno no-manejado, es mucho más facil cometer errores que permitan ataques de tipo buffer overrun que son uno de los vectores de ataque más típicos. En java o .net no existe aritmetica de punteros, por tanto es mucho más difícil que tu código sea vulnerable a este tipo de ataques.
Otro caso parecido donde la tecnología/framework facilita las cosas es con SQL-injection, si usas JDBC y prepared statement se acabo el problema, si haces querys concatenando strings y lanzadolas a la bd incurres en un grave riesgo.
Coincido en que al final el responsable es siempre el programador, y los frameworks/tecnologías en los que se apoye pueden facilitar o no algunas cosas pero desde luego no son los culpables de los problemas de seguridad de tu aplicación (salvo casos específicos, como por ejemplo una vulnerabilidad descubierta hace no mucho en versiones de rails, pero no es de esto de lo que habla el articulo).
En lo que no estoy de acuerdo es que cambiar de framework sea parte del problema, el problema es que la gente no tiene muchos conceptos de seguridad básicos interiorizados. Por ejemplo si te dedicas al desarrollo web tienes que al menos conocer el OWASP y saber decir en que estado esta tu aplicación como poco en referencia al top 10 de vulnerabilidades que publica. Un ejemplo, la número 5 es CSRF, ¿cuantos desarrolladores web pensais que podrían describir correctamente en que consiste un ataque CSRF y como evitarlo?. Teniendo estos conceptos claros da igual el framework que uses.
Como decía un amigo mio, el problema es que tenemos a niños haciendo el trabajo de hombres y luego cuando vienen los problemas nos hacemos los sorprendidos y nos llevamos las manos a la cabeza.
SQL-injection, si usas JDBC y prepared statement se acabo el problema
Nunca subestimes lo malo que puede ser un mal programador. Yo he visto como un tío concatenaba trocitos para hacer una select y luego metía el String en una sentencia preparada. :-D
jeje, claro juan, yo siempre digo que como en la peli jurasick park "la vida se abre paso", el mal programador también se abre paso ante cualquier barrera. Por eso decía que las tecnologías en todo caso facilitan más o menos las cosas, pero como siempre en desarrollo de software, lo que cuenta son las personas.