Lo que se a dado en llamar la Web 2.0 es sin duda el camino a una experiencia más rica para los usuarios de aplicaciones web, pero según Shreeraj Shah en su artículo 'Top 10 Web 2.0 Attack Vectors' , tambien es un nuevo caldo de cultivo para nuevas vulnerabilidades y vectores de transmisión de virus y ataques. El artículo me ha parecido especialmente interesante, por eso me he decidido a traducir la listas de esos vectores con el afán de tenerlos siempre en cuenta, a modo de checklist de comprobación, para más información os remito al artículo original.
Aquí va la lista de vectores de ataque en aplicaciones Web 2.0 y una breve descripción de cada uno de ellos:
Cross-site scripting en AJAX: Las vulnerabilidades basadas en XSS son ya unas viejas conocidas de todos los desarrolladores web, pero sin duda el amplio uso de JavaScrip que hace AJAX hace que estas tomen una nueva dimensión.
Envenenamiento XML: Muchas aplicaciones Web 2.0 mueven datos entre el servidor y el cliente en forma de XML. Es relativamente facil crear XML malformado, que unido a un parseo poco cuidadoso del mismo en el servidor, puede degenerar en una denegación de servicio. Debemos validar en cualquier caso todo XML recibido en el servidor.
Ejecución maliciosa de código AJAX: Las llamadas AJAX se ejecutan en segundo plano sin la interacción directa del usuario. Esto hace que el usuario no siempre sea consciente de las activdades que esta realizando un determinada web, lo que una web maliciosa puede aprovechar para, por ejemplo, hacerse con cookies de autentificación.
Injección RSS / Atom: Esta tecnica consiste en inyectar código JavaScript en el RSS o Atom para que el navegador lo ejecute. Casi todos los navegadores son capaces de mostrar feeds RSS o Atom. Si nuestra aplicación produce un RSS o un Atom deberiamos validar su contenido antes de enviarlo al cliente.
Enumeración y escaneo WSDL: Básicamente los posibles atacantes pueden encontrar un motón de información sobre simplemente viendo la información que nosotros publicamos sobre nuestros servicios web. Debemos proporcionar el acceso más limitado posible a nuestros WSDLs.
Validación (unicamente) de cliente en rutinas AJAX: La validación en cliente en la aplicaciones Web 2.0 es muy rica, esto ha hecho que algunos desarrolladores no hagan estas misma validaciones en el servidor. Esto es un error porque es facil crear una petición y enviarla al servidor saltandose la validaciones de cliente. Por ello las validaciones de cliente siempre deben ser respaldadas en el servidor.
Cuestiones relacionadas con el enrutado servicios web: WS-Routing permite enviar un mensaje SOAP debidamente encriptado por un camino de servidores, pero si un solo servidor de ese camino se ve comprometido, nuestro mensaje SOAP puede ser comprometido.
Manipulación de parámetros con SOAP: Es posible crear mensajes SOAP malformados que intenten realizar inyecciones clasica tipo SQL, XPATH, LDAP o de comandos.
Injección XPATH en mensajes SOAP: Es un proceso similar a las inyecciones de SQL sobre bases de datos, solo que utilizando XPATH como lenguaje de consulta y documentos XML como destino del ataque.
Manipulación binaria del cliente rico ligero: La aplicaciones utilizan componentes ActiveX, Flash o Applets, que ya han demostrado historicamente que son caldo de cultivo para virus y otros tipos de malware.
Sin duda alguna que son puntos muy importantes a tener en cuenta, y justo es un tema que ahora se viene discutiendo, si vemos el conjunto de vectores que se mencionan la mayoria estan relacionos a servicios Web. Justamente Dino Espósito nos da algunas características que deben tener estos y para que usarlo, cuando y donde. aca está la URL http://weblogs.asp.net/despos/archive/2006/10/17/Careful-with-Web-Services-in-ASP.NET-AJAX.aspx.
Debemos tener mucho cuidado con la información que se envíe al cliente y en si, buscar opciones mas seguras para diferentes situaciones, por ejemplo centrandonos en ASP.NET Ajax, (Ajax es uno de los pilares de la Web 2.0) debemos hacer llamadas a servicios Web para el caso de listados que no comprometan información crítica de la empresa, ahora si es necesario trabajar con datos mas críticos se podría usar características como el UpdatePanel para lo mismo.
Es una necesidad el comprender de que además de la facilidad con que se pueden trabajar ciertas características en el cliente, tambien es una responsabilidad mayor el protegernos de ataques dañidos como los que muestras rodrigo, y esa responsabilidad recae en nosotros que somos los que implementaremos estas características, si bien estos temas no son nuevos (existe bastante documentación al respecto desde hace buen tiempo atrás), es necesario tomar las precauciones del caso.
Saludos 🙂
Ivan Mostacero.