Desde el momento en que algo "puede" bajarse a cliente, pues... La
seguridad se termin�. Tendr� la inherente a la plataforma utilizada (applet
java, swf, director..), pero nada m�s.
Una forma de hacer que "no se lo puedan descargar" es lo mismo que
se hace con im�genes o PDFs, que es tener un .php o lo que sea (me da igual
el lenguaje), abrir "en crudo" el archivo que quieras mandar por HTTP (en
este caso, un archivo swf), leerlo, y enviarlo por HTTP (hacer un
response.write o un echo del fichero en crudo....), con las cabezeras Mime
correspondientes.
Evidentemente, parto de la idea de que el archivo .swf solamente es
accesible desde el servidor, y no desde el navegador... Algo tan sencillo
como crear un directorio con .htaccess y darle permisos de solo lectura a
www-data (generalmente el usuario por defecto de Apache, en sistemas
linux-Apache). De todas formas, si averiguan el directorio, y el nombre
"real" del fichero, podr�an descarg�rselo igual... Con lo cu�l has de
implementar la seguridad del lado de servidor, para que las acciones que
consideres "malignas" no puedan hacerlas salvo usuarios bien autentificados.
Hay qui�n dir� que este planteamiento ser�a m�s seguro si se pone el
directorio de "archivos restringidos" por encima del wwwroot de Apache; y
contesto: si y no. Evidentemente, as� autom�ticamente no es accesible desde
el navegador (salvo que algui�n cree un enlace desde los directorios
publicados por apache a este directorio restringido), pero eso crea un par
de problemas adicionales; por un lado, el usuario www-data de Apache tiene
permisos "fuera" de d�nde debe tenerlos (el directorio de publicaci�n de
apache), lo cu�l puede llegar a ser peligroso, y puede ser una fuente de
ataques XSS, con lo cu�l la programaci�n y configuraci�n de permisos del
sistema ha de ser muy cuidadosa. Por otro lado, la aplicaci�n que
construyamos as�, no ser� tan portable, porque no todos los ISP nos
permitir�n "salir" del directorio de publicaci�n para crear un directorio
restringido d�nde metamos los archivos "privados" que queramos.
Bueno, despu�s del "tost�n", espero que os sean �tiles las
opiniones.
Y partir siempre de que todo sistema es, por definici�n, inseguro.
Lo m�s importante es minimizar las fuentes o accesos a dicho sistema.
Saludos.
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre
de Manu Alvarez
Enviado el: jueves, 21 de abril de 2005 12:59
Para: [email protected]
Asunto: Re: [ASNativos] Seguridad swf
Pues lo he estado preguntando, y lo de los directorios privados me da a mi
que no va a poder ser, porque a efectos de navegador todo es lo mismo...
Cuando alguien sea capaz de encapsular un swf que nadie pueda decompilar le
doy un beso en los morros.
----- Original Message -----
From: "Fede Rivas" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, April 21, 2005 12:27 PM
Subject: RE: [ASNativos] Seguridad swf
Yo lo uso exactamente de la misma forma con PHP , 1� autentico la sesi�n a
nivel php y luego flash se encarga de llamar al php que corresponda , el
cual por si mismo sin estar autenticado previamente no funciona , asi aunque
decompilen el swf no podran hacer nada de nada.
De todos modos , seg�n planteas tu pregunta creo que el fallo esta en como
has planteado la autenticacion y la posterior carga del swf que pertenece a
la zona "restringida".
Una solucion que podria servir es meter ese .swf "privado" en un directorio
de acceso restringido en tu servidor , de manera que si accedes a el
directamente desde el navegador no sea posible. Osea digamos :
www.pagina.com/directorioprivado/archivo.swf
en lugar de :
www.pagina.com/archivo.swf
Deber�a de poderse acceder a ese directorio unicamente desde dentro del
propio servidor , y no desde fuera .
Prueba a ver que tal .
Un saludo !!
Fede Rivas .
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre
de eemece2
Enviado el: jueves, 21 de abril de 2005 10:41
Para: [email protected]
Asunto: Re: [ASNativos] Seguridad swf
Hola lista,
Perdona Antonio, no he seguido todo el tema e igual lo que digo ya se ha
dicho o no procede aqui , pero viendo para que lo quieres te comento algunas
pruebas que hice yo:
Desde Actionscript accedo a un 'web service'. Con estos pasos:
El primero es una funci�n de autenticaci�n (usuario, password), que en caso
positivo, en el servidor, autentica la sesion.
El segundo paso es acceder ya al metodo de envio del email, que comprueba
(encodigo de servidor) que la sesion este autenticada para permitir el envio
del email.
Es decir, resumiendo, que me valgo de la autenticaci�n de la sesion, y
aunque decompilen el SWF y vean que llama a un Web service, no podran
utilizarlo sin hacer un 'login' previo con el metodo 'login' del web
service..
Yo uso asp.net y web services, pero supongo que con php, etc, y con
peticiones normales de parametros o XMLs se podra hacer tambien, siempre que
puedas gestionar las sesiones.
�Van por ahi los tiros?
Un saludo,
Edu
----- Original Message -----
From: "Antonio Rico Ortega" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, April 21, 2005 8:56 AM
Subject: RE: [ASNativos] Seguridad swf
Hombre a mi el codigo me da lo mismo , ademas yo soy el primero que a
decompilado algo porque en mi opini�n es una de las mejores maneras de
aprender. El asunto es que ese swf permite el envio de un formulario a un
mail al que es imprescindible la verabilidad de los mensajes y es por eso
por lo que hay una previa indentificacion.
Muchas gracias a todos los que habeis propuesto una soluci�n utilizando bien
un lenguaje servidor , bien por javascript. Lo que me habeis dejado claro es
que tendremos que esperar a que MacroADOBEmedia saque algo para el propio
flash.
Un saludo
www.publibanus.com
[EMAIL PROTECTED]
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre
de Joseba Alonso
Enviado el: mi�rcoles, 20 de abril de 2005 23:18
Para: [email protected]
Asunto: RE: [ASNativos] Seguridad swf
No existe ninguna forma de evitar la descarga del archivo. Vamos, hay mil
maneras de hacerlo.
De todas maneras, si ver el c�digo del swf implica algun problema de
seguridad, es que algo estas haciendo mal. Lo razonable seria que no lo
fuese. �Qu� hay en el swf que piensas que no se deber�a de conocer?
Joseba Alonso
www.5dms.com
www.sidedev.net
> -----Mensaje original-----
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En
> nombre de Antonio Rico Ortega
> Enviado el: martes, 19 de abril de 2005 23:30
> Para: [email protected]
> Asunto: [ASNativos] Seguridad swf
>
> Muy buenas a todos,
>
> Estoy desarrollando un programa de acceso identificado que como resultado
> accede a una pagina que carga un swf. El problema es que el navegador te
> deja cargar directamente el swf si pones la direccion excta en la barra de
> direcciones, por ejemplo www.pagina.com/archivo.swf
>
>
>
> Mi pregunta es si exite algun metodo para impedir la carga directa del
> mismo
>
>
>
> Muchas gracias por adelantado
----------------------------------
Lista ASNativos:[email protected]
http://www.5dms.com/listas
----------------------------------
----------------------------------
Lista ASNativos:[email protected]
http://www.5dms.com/listas
----------------------------------
----------------------------------
Lista ASNativos:[email protected]
http://www.5dms.com/listas
----------------------------------
----------------------------------
Lista ASNativos:[email protected]
http://www.5dms.com/listas
----------------------------------
----------------------------------------------------------------------------
-----------------------
Texto a�adido por Panda Client Shield:
Este mensaje NO ha sido clasificado como SPAM. Si se trata de un mensaje de
correo no solicitado (SPAM), haz clic en el siguiente v�nculo para
reclasificarlo: http://127.0.0.1:6083/Panda?ID=pav_710&SPAM=true
----------------------------------------------------------------------------
-----------------------
----------------------------------
Lista ASNativos:[email protected]
http://www.5dms.com/listas
----------------------------------
----------------------------------
Lista ASNativos:[email protected]
http://www.5dms.com/listas
----------------------------------
