Google: Cookies y Cross Site Scripting (XSS) (I)

Tranquilos, no es que esté molesto con la gente de Google por no dejarme jugar a "The Ultimate Search For Bourne With Google" desde linux y por tanto vaya a revelar información sensible acerca de como usar las cookies de sesión para realizar un ataque de Cross Site Scripting (XSS).

Más bien al contrario, en esta ocasión voy a comentar dos noticias aparecidas en sendos blogs del gigante de Internet acerca de innovaciones y/o cambios en sus políticas de seguridad.

Por un lado, en el blog oficial de seguridad nos indican, tras una breve introducción de qué es un ataque de Cross Site Scripting y algunos consejos prácticos sobre como mitigarlos, las medidas que Google está tomando para securizar sus aplicativos web.

Según Srinath Anantharaju, autor de la noticia y miembro del equipo de seguridad, su equipo ha desarrollado un sistema de pruebas llamado "Lemon", el cual utilizan para inyectar peticiones a sus aplicativos web y ver las debilidades de éstos ante este tipo de ataques. Además según comenta, estas pruebas les han ayudado a encontrar otros fallos de seguridad.

En mi opinión, hay que aplaudir este tipo de medidas por parte de empresas de tan gran envergadura, si bien es cierto que considero que este tipo de medidas deberían ser de obligado cumplimiento para todas las empresas que ofrezcan desarrollos o servicios web. Ahora a ver si el resto de empresas se va concienciando poco a poco (o mucho a mucho) de la situación y problemática actual y empieza a poner medidas.

Además seria conveniente que se empezara a popularizar el uso de los denominados firewalls de [capa de] aplicación. Estos elementos también llamados firewalls de capa 7, realizan su labor en la capa 7 del modelo de referencia OSI. Para ello interceptan las peticiones de un protocolo determinado (en nuestro caso HTTP) a modo de proxy; examinan y filtran el contenido de dicha petición; en caso de no ser rechazada la re-encapsulan y reenvían al servidor que corresponda; una vez que éste responde, se analiza la página web resultante que se va a devolver para comprobar que no hay patrones sospechosos; se elimina todo el contenido "anómalo" de la respuesta y el resultado se le envía al usuario final.

Por supuesto esta medida no excluye la securización de código. Recordemos por ejemplo el caso de los ataques de Blind SQL, que resultan exitosos pese a no obtener información a través del aplicativo web, por lo que ambas soluciones deberían ser siempre complementarias la una de la otra.

Como este post se me está alargando un poco más de lo debido, lo continúo en el siguiente y así facilito la lectura.

En seguida más.