El equipo de seguridad de Google han liberado como opensource su herramienta Ratproxy que permite una auditación de sitios web para buscar fallos en la seguridad. La herramienta realiza varias pruebas de seguridad para detectar vulnerabilidades como XSS, scripts cross-domain, problemas en el cache y un largo etcétera.
Puedes encontrar una lista detallada del funcionamiento de este proxy en la documentación del proyecto. La herramienta se enfoca en dar informes concisos sobre potenciales problemas de seguridad en aplicaciones web 2.0 y es resultado del trabajo diario de Google en el área de seguridad de sus aplicaciones; por lo que es capaz de diferenciar entre código javascript y css, decompilar contenido Flash on-the-fly, trabajar sobre SSL, etc.
La seguridad es un tema que lamentablemente se deja de lado al desarrollar aplicaciones web, herramientas como ésta buscan que se simplifique este trabajo ( existen otras similares como WebScarab de OWASP o Paros). Obviamente, las herramientas se deben complementar con una buena política y otras herramientas de logs y monitorización e incluso con pruebas manuales. ¿Que es lo que vosotros usáis para garantizar la seguridad de vuestras aplicaciones?
Etiquetas: otro, Seguridad, Google
Totalmente de acuerdo en que la seguridad es un aspecto olvidado dentro del proceso de desarrollo de las aplicaciones web y que la automatización del proceso de auditoría es importante.
De todas formas, desde mi punto de vista la principal tarea a automatizar es la securización de las aplicaciones, no en detectar que las aplicaciones son inseguras. Es decir, desarrollar una aplicación web segura en los frameworks web actuales, incluso en muchos de los más recientes no es nada fácil y una herramienta de auditoría no automatiza esta tarea.
Creo que herramientas como HDIV, que realmente automatizan el proceso de securización, son las que aumentan el nivel de seguridad de las aplicaciones web. De todas formas nunca esta demás revisar esa seguridad mediante un proceso de auditoría.
Habitualmente la seguridad basada en auditorías de seguridad son solventadas mediante "parches" propietarios debido a la carencia de soluciones reales ofrecidas por los frameworks web, estando obligados a volver a auditar la aplicación cada vez que se realizan cambios sobre la aplicación.
Por lo tanto, entiendo que es prioritario invertir en la automatización del proceso de securización en el desarrollo de la aplicación y no tanto en la auditoría posterior.
Compañero, muchas gracias por la referencia a HDIV, no lo conocía y lo tendré en cuenta el dia que vuelva al desarrollo web, me ha parecido interesante encontrar algo así. Gracias
Salu2
De todas formas así a ojo el 90% de los problemas de codigo se solucionan escribiendolo correctamente con buenas practicas. Echandole una capa encima con cosas como HDIV quizá se pueda "tapar", pero el codigo seguira siendo una ***** y el día que por a por b le quiten la capota de seguridad a la aplicación, la gente se desmayará por lo que hay debajo.
Quiero decir que, aparte de una solución, es tambien un sintoma si tenemos que hacer las cosas así.
Claro que solucionarlo significaría escribir código de calidad, tener programadores formados... el pan nuestro de cada día, vamos :).
Quiero verlo de un modo más positivo ;-) Por muy buen programador que seas y por muy buen proyecto que desarrolles, es fácil que se te cuele un gazapo. Asi que veo HDIV como un pequeño guardaespaldas que está ahí por si he tenido un mal dia al programar cierta parte de mi web ;-) Además, no siempre es fácil estar a la última en ataques, ni controlarlos todos... que se preocupen los de HDIV por mi...
Salu2
Estoy de acuerdo con lo comentado por Ibon. Por mi experiencia, la seguridad basada en buenas prácticas, es decir, reglas que los programadores tienen que seguir pero que son extremadamente difíciles de verificar si se están cumpliendo o no, tienen una probabilidad muy alta de la existencia de errores, incluso en aquellos casos en los que existen programadores formados y se genera código de calidad.
Lo mismo ocurre con la mayoría de aspectos que engloban un desarrollo de un proyecto: acceso a base de datos, manejo de excepciones,..
Un ejemplo claro de esta idea es la propia historia de Java. La bibliografía de Java y de la programación orientada a objetos esta llena de "buenas practicas" que los "buenos" programadores tenemos que seguir, eso si implementando esas buenas prácticas de forma manual. Con soluciones como Spring muchas de estas buenas prácticas son implementadas de forma automática gracias a una librería. Por ejemplo, cerrar las conexiones de BD o tratar adecuadamente las excepciones eran una buena práctica de programación hasta que los señores de Spring crearon una librería que cierra las conexiones y trata las excepciones de forma automática.
Evidentemente esto no implica que los programadores no tengan que conocer cual es la forma correcta de cerrar las conexiones o tratar las excepciones.
Además, por lo menos en los proyectos de mi entorno y creo que en la mayoría, no sobra el tiempo para estar verificando continuamente la seguridad, siendo prioritario acabar en la fecha prevista.
Intentar solucionar vulnerabilidades como la A4 de OWASP (Insecure Object Reference) de forma programática y manual me parece un infierno respecto a una solución mediante una librería que no me exige ningún tipo de esfuerzo y me garantiza la seguridad, por lo menos sobre lo referente a esta vulnerabilidad.
Utilizar una librería de seguridad externa al código propietario de la aplicación ya sea HDIV o Acegi por ejemplo no hace ni mejor ni peor el código de las aplicaciones. En general opino que siempre es recomendable no reinventar la rueda y utilizar soluciones de calidad ya existentes.
De todas formas, comparto la idea de fomentar la creación de código de calidad e invertir en la formación de los programadores, que a la postre son los que marcan la calidad de cualquier proyecto.
No es que diga que no haya que usar librerías así ni nada, sólo decía que no creo que haya que descuidar la otra parte, sólo por tener algo que me lo cubra. Y en el mundo de las aplicaciones Java tampoco es tan tan complicado ni hay que "estar a la última". Con no concatenar strings para hacer el SQL, no escribir directamente el input que te mandan en la página de vuelta, poner los ficheros de configuracion dentro de WEB-INF, uno cubre el 80% de los casos más habituales.
Para el otro 20%, que es más dificil de tratar, es donde veo más util la librería. Pero el otro 80% ya debería estar cubierto o estamos haciendo codigo de mala calidad, con una capita de pintura.
Yo sí conocía HDIV y me gustaría comentar lo siguiente para los que no lo sepáis. En el Top 10 de OWASP se enumeran las 10 vulnerabilidades web más comunes y en varias de ellas, en concreto en las vulnerabilidades A4 (Insecure Direct Object Reference), A5 (Cross Site Request Forgery) y A10 (Failure To Restrict Url Access) se propone a este framework (HDIV) como solución. En mi opinión creo que soluciones de este tipo nos ayudan a desarrollar aplicaciones más seguras olvidándonos así de tener que implementar soluciones propietarias en cada aplicación web. No creo, en mi opinión, que soluciones de este tipo nos lleven a dejar de lado las "buenas prácticas" o "buenos desarrollos" aquí comentados. No deberíamos de olvidar que aunque hay ciertas vulnerabilidades web, como por ejemplo la A2 (Injection Flaws) [SQL Injection] de OWASP, que se pueden evitar no concatenando Strings, como comenta greeneyed, hay vunerabilidades como la A4 (Insecure Direct Object Reference) que es complicadísimo de solucionarla de forma propietaria. En mi grupo de desarrollo optamos hace unos meses por el uso de HDIV y nos ha quitado muchos quebraderos de cabeza que teníamos antes cuando teníamos que implementar "nuestro invento" en cada aplicación.
Sería interesante que comentáramos qué soluciones usamos en nuestros equipos de desarrollo para solucionar vulnerabilidades como por ejemplo la última comentada (A4). Cómo solucionamos el 20% comentado por greeneyed (difícil de solucionar)?
Yo estoy encantado de que existan APIs de desarrollo seguro y nos automaticen y agilicen el desarrollo web. Lo mismo que estoy encantado con librerías como Spring, aquí comentada, que también me ha automatizado la "vida". ;-)
Se me olvidaba! creo que después de comentar mi experiencia de desarrollo con estas nuevas APIs, sobra comentar que herramientas como Ratproxy nos ayudan a la realización de Auditorías pero en ningún caso nos ayudan durante la fase de desarrollo, aunque sí, insisto, en la fase de pruebas y auditorías.
.i.
Escribe tu comentario