Restricción de la visibilidad del archivo SWF

Tengo una situación en la que mi archivo SWF principal carga muchos archivos SWF externos. Sin embargo, esos archivos SWF externos solo se encuentran en la carpeta pública del servidor web.Restricción de la visibilidad del archivo SWF

Es posible restringir la visibilidad del SWF a solo mi archivo SWF principal (el que carga los SWF externos). En el estado actual, cualquier usuario que sepa dónde buscar puede simplemente escribir la URL y acceder a los archivos SWF, sin mencionar los robots deshonestos que no siguen a robots.txt.

La razón de esto es muy simple. Los usuarios usan un nombre de usuario/contraseña para iniciar sesión en la aplicación principal de Flash y la aplicación principal de Flash carga los archivos SWF y SÓLO luego están disponibles para el usuario. Además, según quién sea el usuario que haya iniciado sesión, algunos archivos SWF están restringidos y no están cargados.

¡Gracias por cualquier ayuda!

Fuente

2010-03-07 helloworlder

No estoy tan familiarizado con Flash así que no sé qué posibilidades específicas de Flash existen para esto, pero esto podría resolverse haciendo el inicio de sesión en un lenguaje del lado del servidor como PHP o ASP. Un inicio de sesión crearía una sesión y una sesión válida sería la condición para la entrega de los archivos subsiguientes. –

Gracias Pekka. Estuve entreteniendo esta idea, pero estoy bastante seguro de que Flash solo puede cargar activos externos (incluidos los SWF) solicitando una URL (los SWF no se pueden entregar * a *). Si es verdadero, Flash nunca podrá llegar a los SWF si están protegidos de alguna manera. – helloworlder

Solo tenía otro pensamiento. ¿No es posible evitar que un directorio aparezca en la lista modificando .htacess? Por lo tanto, no se puede enumerar, pero aún puede abrir archivos si conoce el nombre exacto. Tal vez sea posible hacer que el nombre sea imposible de obtener añadiendo un hash al final del nombre del archivo. * prácticamente imposible – helloworlder

Depende de cómo se autentica el flash. Flash necesita autenticarse con una aplicación del lado del servidor con una base de datos. La aplicación del lado del servidor puede usar una base de datos para realizar el control de acceso por archivo.

Todo files debe realizar un seguimiento de una mesa, contiene columnas como el path local al archivo, así como user_group o tal vez un user_id. La sesión autenticada debe realizar un seguimiento del user_id después de que hayan iniciado sesión con un nombre de usuario y contraseña.

Es común que las arañas de ataque usen robots.txt en su contra, si coloca estas rutas de archivos en su archivo robots.txt es mejor que simplemente las levante y se las entregue al atacante.

Es muy fácil descompilar aplicaciones flash y modificarlas. No confíe en los sistemas de seguridad del "lado del cliente", son muy fáciles de eludir. Un atacante también puede reproducir y modificar solicitudes HTTP utilizando tamperdata.Necesita un servidor para decirle al cliente a qué archivos puede acceder.

Fuente

2010-03-07 17:59:38 rook

Hola, gracias por la respuesta! Estaba pensando en utilizar un método como este, pero el problema es si los SWF externos están en un directorio protegido, es decir, no visibles públicamente, entonces Flash tampoco podría cargarlos, ¿no? Creo que el principal problema es que no puede pasar objetos SWF a una aplicación Flash. Solo una aplicación Flash puede cargar objetos SWF al referirse a una URL real. ¿Entonces tal vez no sea posible? :-( – helloworlder

Bueno, supongo que si no es posible tendré que llegar a algún tipo de compromiso. El problema de derechos de autor con respecto a los SWF es un poco complejo, pero esa es la naturaleza del requisito comercial. Si se trata de un compromiso de seguridad, entonces tengo para dejarlo en claro a mi cliente. Un compromiso de usabilidad podría ser otro camino por recorrer. Tal vez pueda convertirlo en una aplicación de escritorio AIR en su lugar y los usuarios iniciarán sesión en la aplicación web y verán los archivos SWF "que pertenecen" disponibles para su descarga. Ellos descargan esos archivos SWF del servidor a su computadora para que la aplicación AIR pueda acceder a esos archivos. – helloworlder

Dependiendo de qué tan seguro que desea ser, puedo pensar en un par de opciones:

un script del lado del servidor para controlar la entrega de sus sub-fondos soberanos (como Pekka ha sugerido más arriba).
Si queremos hacer todo del lado del cliente, se puede poner una prueba condicional dentro de cada sub-SWF, por lo que sólo se reproducirá desde el interior de su swf principal:

Algo así como if(this.parent.toString() != "mainSwf") { stop();} (en pseudocódigo)

De acuerdo, esto no es infalible, ya que alguien podría crear fácilmente su propio padre llamado "mainSwf", pero impediría la búsqueda casual de sus sub-archivos swfs. Al menos hasta que alguien los decompiles ...

usted podría hacer las cosas un poco más difícil estableciendo una propiedad dentro del SWF principal, como var myKey:String="362574036704ry3f0y3432607", a continuación, utilizar el condicional para la prueba de que: if(this.parent.myKey != "362574036704ry3f0y3432607") { stop();}.

Alféizar no es terriblemente seguro, sin embargo. Espero que esto ayude.

EDIT:

También hay una pregunta similar here, lo que podría tener respuestas útiles.

Fuente

2010-03-07 16:12:49

-1 No puedes proponer una vulnerabilidad en SO, especialmente si sabes que es una vulnerabilidad. Descompilar el flash o reproducir las solicitudes GET con tamperdata puede omitir el sistema de seguridad del lado del cliente. – rook

@The Rook: ¡Jeje, me aseguraré de leer las Preguntas más frecuentes con más atención la próxima vez! Pero déjame saber cómo crees que GET sniffing va a romper este método. Y sí, a veces una solución del lado del servidor no es posible por otras razones ... supongo que vivimos en un mundo imperfecto. :) –

Restricción de la visibilidad del archivo SWF

Respuesta

Cuestiones relacionadas