Es mucho mas facil de como lo pintas tirar una base de datos :
Si la conexion a la base de datos no es por medio de dsn ,te la pueden tirar
en cualquier momento ,si es de lectura y escritura.Declarar dns cuesta (en
el servidor q yo uso 15 pepinos anuales por cada una).
Pero hay muchos mas truquillos ,por ejemplo ,puedes ejecutar sql a traves de
formularios si no te aseguras que el usuario no pueda meter comillas....
lo dicho ,que para montar un sitio seguro, hay que empollarse muchos
truquillos famosos ,por ejemplo el de sql.
Pablo Cirre
----- Original Message -----
From: "Felipe Alonso" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 19, 2001 8:22 PM
Subject: RE: [flashmaestro] desproteccion de flash
> Os reenvio este correo escrito por Sixto Cantolla
> ______________________________________________________
> Hola a todos:
>
> Esta es mi primera intervenci�n en la lista, y espero que no sea la
�ltima,
> :), a pesar que llevo bastante tiempo apuntado. Bueno, no me enrrollo.
>
> Pedro, te lo comento a ti de forma personal, por que has escrito el �ltimo
> mensaje, pero es un comentario al aire:
>
> Primero, el servidor seguro, hasta cierto punto no existe, pues el hacker
> profesional se puede colar con paciencia en cualquier sitio aunque cada
vez
> se lo ponen m�s dif�cil, gracias a Dios, hay muy poquitos de esos (desde
un
> punto de vista comparativo) y los que existen se dedican a atacar a
grandes
> empresas abanderadas del capitalismo (bancos,etc...), o a departamentos de
> gobiernos. Es un servidor con ciertos niveles de seguridad, no puedes
listar
> el contenido de directorio, a no ser que introduzcas el usuario y el
> password adecuado, y al hacer una llamada a un asp, este se ejecuta en el
> servidor de forma opaca, es decir, en ning�n momento el asp sale a la red
> como c�digo, de forma que con ning�n software de escucha se puede acceder
al
> c�digo del asp, que es el verdaderamente importante, pues es el que
negocia
> con la base de datos (que a su vez est� alojada en el mismo servidor, por
lo
> que la negociaci�n tampoco se puede "escuchar" y por tanto capturar la
> informaci�n). Por otra parte se supone que el servidor no permite la
> descarga de ning�n tipo de archivo que no est� en un directorio espec�fico
> en el que no hay nada que no quieras que se descargue. Por favor,
corr�geme
> si me equivoco en algo.
>
> Bien, entonces esa parte es segura (hasta cierto punto), vamos ahora a la
> parte de Flash o html. Realmente la programaci�n de html y flash, son
> paralelas, pues en ning�n momento se tiene por que introducir informaci�n
> que comprometa la base de datos, mas que el nombre de la p�gina ASP que
> realiza la negociaci�n con la base de datos (que como ya hemos quedado es
> "incorruptible"), ahora bien, cuando se piden los datos del usuario (id y
> password p.ej.) y se env�an al asp es ah� cuando tenemos un agujero de
> seguridad en el sistema, pues con un software de escucha simple dirigida a
> la IP (huella digital del ordenador) del usuario que accede a la p�gina
web,
> puedes capturar los datos que env�as. Para evitar eso, se desarrollaron
las
> conexiones seguras (HTTPS), que tiene un sistema de encriptaci�n en la
> m�quina cliente de 128 bits, y un desencriptador en la m�quina destino,
que
> lleva asociado una "llave", la explicaci�n del sistema es muy extensa,
> adem�s de que hay documentaci�n en la red que lo explica de forma mucho
> mejor de lo que lo pueda hacer yo. Como dato, este sistema de
encriptaci�n,
> se ha estimado que con 100 superordenadores trabajando 24 horas al d�a, se
> tardar�a en desncriptar unos 7 a�os (con la tecnolog�a de hoy en d�a), el
> dato est� citado de memoria, por lo que no ser� exacto, lo que quiero
decir
> es que el nivel de seguridad de este tipo de conexi�n es alt�simo. Por lo
> que, sea en flash o html son igual de seguras.
>
> Mi conclusi�n personal es que da igual que tecnolog�a uses, simplemente
> escoge y �sala bien, todas son igual de validas, siempre y cuando tengas
los
> conceptos claros b�sicos de seguridad y sigas unas reglas de oro:
>
> 1. Escoge un servidor en el que te den por escrito garant�as de su
seguridad
> interna e impenetrabilidad del sistema, no te f�es de los servidores
> baratos, los caros no garantizan algo mejor, pero los baratos no dan mucha
> sensaci�n de seguridad, siempre pide garantias. Si el servidor es tuyo,
> contrata a un t�cnico inform�tico con amplios conocimientos de seguridad
> para mantenerlo.
>
> 2. Como bien dices, no pongas nada que no quieras que se sepa ni en un
html,
> ni flash, ni nada, repito nada, que se ejecute en la m�quina cliente (la
del
> usuario).
>
> 3. Cualquier envio de informaci�n susceptible de comprometer el sistema,
> hazlo a trav�s de conexi�n segura, nunca envies informaci�n a trav�s de
http
> que no quieras que se vea.
>
> 4. Y nunca creas que est�s a salvo, pues much�simos virus funcionan como
> esp�as en las m�quinas que infectan, ante lo cual tu no puedes hacer nada,
> s�lo confiar en que el usuario sea responsable y tenga un antivirus
> actualizado.
>
> Sobre todo no hay que asustarse por las posibilidades de que rompan la
> seguridad del sistema pues hoy en d�a hay muchas tiendas virtuales y
grandes
> bases de datos funcionando en internet que no han sido "reventadas" y como
> tu bien dices algunas de ellas obvian de forma escandalosa las m�nimas
> normas de seguridad para sistemas de ese calibre.
>
> Creo que no me queda m�s por decir, s�lo te pido encarecidamente, que si
me
> equivoco en algo, me corrijas y trasmitirte mi admiraci�n Pedro por tu
talla
> profesional.
>
> Un saludo a la lista y a los administradores de la lista
>
> Sixto Cantolla
> Director t�cnico
> Azulmedia 2000
>