Como ya saben, las peticiones usando el objeto XMLHttpRequest -o su equivalente en IE-, están limitadas por defecto al mismo dominio.
Cuando el objeto XMLHttpRequest funciona en un navegador, se adopta la misma política de seguridad típica de JavaScript. Mozilla requiere envolver el objeto dentro de los privilegios de seguridad UniversalBrowserRead. IE, por otra parte, simplemente muestra una alarma al usuario de que una actividad potencialmente insegura puede continuar y ofrece una posibilidad para cancelar. El dominio de la URL de destino de la petición debe ser el mismo que el de la página que se visita. Esto quiere decir, que los scripts no pueden traer ni enviar datos a otras fuentes
Si no existiera dicha restricción, se harían más fáciles los ataques del tipo CSRF.
A cross-site request forgery (CSRF), although similar-sounding in name to cross-site scripting (XSS), is a very different and almost opposite form of attack. Whereas cross-site scripting exploits the trust a user has in a website, a cross-site request forgery exploits the trust a Web site has in a user by forging a request from a trusted user. These attacks are often less popular (so there are fewer resources available), more difficult to defend against than XSS attacks, and, therefore, more dangerous.
Bien, este tipo de restricciones también se aplican los applets de java y a las aplicaciones .NET embedidas como objetos ActiveX; para cambiar este comportamiento normalmente hay que configurar y dar los permisos adecuados en cada navegador.
En el caso de Flash, es un poco diferente, ya que para hacer peticiones HTTP desde un dominio A hacia otro B, es necesario que en B exista una regla que indique que el dominio A puede hacer llamadas a B, éstas reglas están definidas en un archivo denominado crossdomain.xml.
<allow-access-from domain="*"/> <!-- Permite el acceso desde cualquier dominio -->
</cross-domain-policy>
Hace algún tiempo, Chris Shiflett publicó unos artículos indicando la peligrosidad que podría tener este archivo así como también algunos sitios populares que eran vulnerables (Flickr, Youtube). El número de sitios que tienen o tenían este archivo -según google- son relativamente pocos, haciendo que sólo estos sitios sean posiblemente vulnerables a ataques CSRF.
Sin embargo, hoy ha sido publicado en Hardened PHP Project, una vulnerabilidad en Flash Player, que permite cargar las politicas de seguridad desde un documento xml malformado. Esto se logra gracias al método loadPolicyFile -que sirve para especificar una ruta alterna para crossdomain.xml- y una imagen GIF que contiene el texto xml mostrado arriba.
Vulnerable Applications
- Applications that use a blacklist approach to only disallow dangerous HTML tags in text/html output
- Applications that do not filter HTML tags because response is not text/html
- Applications that allow fileupload/retrieval (e.g. avatars in bulletin boards)
- Applications that contain PHP include vulnerabilities
- Applications that contain file retrieval vulnerabilities
Policy.gif
00000000 47 49 46 38 39 61 01 01-01 01 e7 e9 20 3c 63 72 GIF89a.......<cr 00000010 6f 73 73 2d 64 6f 6d 61-69 6e 2d 70 6f 6c 69 63 oss-domain-polic 00000020 79 3e 0a 20 20 3c 61 6c-6c 6f 77 2d 61 63 63 65 y>...<allow-acce 00000030 73 73 2d 66 72 6f 6d 20-64 6f 6d 61 69 6e 3d 22 ss-from domain=" 00000040 2a 22 2f 3e 20 0a 20 20-3c 2f 63 72 6f 73 73 2d *"/>....</cross- 00000050 64 6f 6d 61 69 6e 2d 70-6f 6c 69 63 79 3e 47 49 domain-policy>..
Posiblemente un gran número de aplicaciones sean afectados por este problema.
One reply on “Ajax, flash, seguridad y demás yerbas”
Me gustaria que alguien me a yudara con este problema :
como hacer que desde un boton en flash me abra una pagina de html,pero sin tener que dar permisos al swf en internet por que asi si funciona pero cuando no tengo internet no funciona...