Privacidad y ambito WEB de la BD Velneo?

Velneo
1

Hola, estamos acabando de cerrar un proyecto MIXTO, WEB servido por vModApache y App Velneo, y en principio todo ha transcurrido con normalidad, pero anoche me vino un flash a la cabeza que me dejó bastante inquieto, y no sé si he cometido un error de base. Me explico:
- La parte Web del proyecto incluye un Blog que está implementado integramente en v7 y servido por vModApache. Para ello he implementado un editor HTML completo en v7 que hace lo mismo que hace WordPress con un Blog (yo diria que mucho más rápido), hasta aqui genial. Naturalmente para que todo sea fluido, las imagenes que insertamos en los post del blog previamente las tenemos alojadas en nuestra BD. Dado que esta parte se trata de un blog, el hecho de que sean públicas no tiene la menor importancia. Si a algun curioso le da por mirar el código fuente HTML servido y fijarse en la etiqueta de [img /] puede ver la ruta completa de la imagen en nuestra BD, algo parecido a esto:

[ img src="http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_POSTS_IMAGENES/JPG00007.png" / ]

Si el curioso, conoce un poco Velneo, sabrá el nombre de nuestra SOLUCION, de nuestro PROYECTO DE DATOS y de la tabla POST_IMAGENES, en la que Velneo numera "secuencialmente" todas las imagenes JPG00007, JPG00008,JPG00009 ... para su acceso web.
De esta forma si el curioso tipea en la URL de un navegador cualquiera:
http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_POSTS_IMAGENES/JPG00007.png
o
http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_POSTS_IMAGENES/JPG00008.png
o
http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_POSTS_IMAGENES/JPG00009.png
etc...
Tendrá acceso ilimitado a todas la imagenes declaradas en la tabla nuestra BD.

No sería más lógico que la numeración de las imagenes por Velneo no fuera consecutiva y fuera alguna formula alfanumérica, del estilo twiter JPGx4v_3g5j9.png para que nadie pudiera suponer de forma lógica cual es la siguiente imagen de la tabla y acceder a ella a traves del navegador de forma tan sencilla, ME PARECE UN GRAVE ERROR DE SEGURIDAD.

EN FIN, al tratarse de un blog no debería tener mas importancia pero "nada mas lejos de la realidad". Por que de igual modo que existen imagenes en las tablas para el Blog, en nuesta aplicacion existen imagenes en otras tablas que no deberian ser públicas, concretamente imagenes que tienen derechos de copyright y que solo deben servise previo pago.

Si nuestro curioso compra una sola de las imagenes con copyright servida con vModApache y le dá por mirar el codigo HTML veria algo así:
http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_IMAGENES_COPYRIGHT/JPG00001.png
Lógicamente solo tiene que tipear en su navegador:
http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_IMAGENES_COPYRIGHT/JPG00001.png
http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_IMAGENES_COPYRIGHT/JPG00002.png
http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_IMAGENES_COPYRIGHT/JPG00003.png
etc...
etc...
para bajarse por la cara cualquier imagen con copyright que tengamos "inocentemente guardadas en nuestra BD Velneo".

¿POR QUE ESTÁN ACCESIBLES VIA WEB TODAS LAS IMAGENES DE NUESTRA BD?
¿EN QUE ME ESTOY EQUIVOCADO DE PARTIDA?
¿NO DEBERIAMOS PODER DECIDIR EN TIEMPO DE EJECUCION SI LA IMGEN SE DEBE SERVIR O NO?
¿SE PUEDE HACER ESTO, Y YO NO SE COMO HACERLO?
SI NO ES ASI ¿COMO LE EXPLICO ESTE AGUJERO DE SEGURIDAD AL CLIENTE?
¿COMO EXPLICA VELNEO ESTE AGUJERO DE SEGURIDAD?
¿POR QUE ENUMERA TAN INOCENTEMENTE LOS OBJETOS IMAGEN VELNEO?
¿HE PERDIDO UN MES DE PROGRAMACION?

P.D. Hoy en el primer Flash de la pagina de inicio de Velneo curiosamente lo primero que me ha aparecido es : "v7 ES SEGURIDAD", Y CLARO NO HE PODIDO EVITAR ESBOZAR UNA AMARGA SONRISA.

2

Ya que tiras de vModApache, ¿no es mejor que gestiones las imagenes con el Apache?:

Un directorio en el que alojas las imagenes.
Una tabla en la que gestiones los nombres que has querido de las imagenes.
Un proceso en el que subes la imagen con el nombre que quieras.

Luego deberas montar un form paralelo a tu editor HTML para seleccionar la imagen de la tabla que quiere incluir en el blog.

A fin de cuentas, es lo que hace Wordpress, ¿no?

En cualquier caso, el nombre tipo JPGx4v_3g5j9.png se lo deberas dar tu a la imagen, salvo que montes algo para renombrar el archivo en el proceso de subir la imagen al directorio, y el nombre devuelto al subirlo, lo guardes en la tabla para gestionar las imagenes.

No se, se me ocurre.
Saludos ;)

3

Nosotros teníamos un problema parecido y lo solucionamos de la forma mas simple. En una zona privada de clientes, estos podían ver un listado de sus pedidos, y al pinchar en uno de ellos se abría el pedido con sus detalles y sus lineas. Cuando "el curioso" cambiaba el id del pedido en la url, podía ver cualquier pedido de otro cliente, así que para solucionarlo comprobamos si el pedido pertenece al cliente logueado antes de mostrárselo.

En tu caso puedes hacer una tabla histórica de clientes e imágenes para saber quien las compró, y mostrárselas solo a quien las haya pagado. Si no la pagaron no la muestras aun que pongan la url correcta.

Un saludo

4

@innovadb

Creo que son problemas diferentes, me explico.
El pedido lo puedes controlar por el ID en la url, y por tanto en el proceso con el que cargas la info para devolverla en HTML, y ahi si puedes discriminar comprobando el usuario si es correcto MUESTRA, si no es correcto DEVUELVE ERROR, o pagina 404.
Los datos no estan accesibles via web, si no es por proceso que los devuelva en formato X.

Pero la imagen en algun sitio le das la URL montada, aunque la cargues por proceso o link , la imagen ya estara disponible, por tanto, no puedes comprobar nada.
Por lo tanto, en el momento que le muestres la imagen en el navegador, si los nombres son correlativos, no necesita mas que teclear la siguiente como bien dice ikonos, salvo que los nombres sean enrevesados, y no sepa cual sera el siguiente o anterior nombre.

Saludos ;)

5

@Gegeo

Tienes razón, no había interpretado bien el problema. La solución entonces es la que tu propones de las imágenes en una carpeta y mostrarlas por proceso.

Saludos

6

Yo ya lo he dicho muchas veces, no se deberia hacer proyectos serios solo con el vmodapache... Algunos estan de acuerdo parcialmente comigo, otros no estan de acuerdo.

Sinceramente, en mi modesta opinión, y con base a mi experiencia de programar web con velneo, el vmodapache es una gran utilidad para extraer información de nuestras aplicaciones, pero no es ni de cerca una solución para web (y al mejor no tiene porque serlo).

Y lo digo muy en sério, iniciar un proyecto grande solo con vmodpache, sin tener un intermediario por medio, puede a medio plazo salirnos muy caro..

Existen bastantes herramientas y lenguajes con decadas de experiencia y de vida, y aún así si encuentra uno que otro fallo de seguridad.

Por eso en su dia he escrito este articulo: http://blog.digitalsoftlab.com/2011/11/pagina-web-en-velneo-v7-parte/

7

@ a los dos, Gracias por los comentarios.

Efectivamente, el problema es que cuando conectamos una DB Velneo por vModApache a un servidor Apache, para acceder a "TODAS" las imagenes del proyecto no necesitamos devolver un proceso HTML (que podemos controlar perfectamente) sino que se puede referenciar directamente cualquier imagen de cualquier tabla con la direccion URL "http://www.myDomain.com/SOLUCION/obj/PORJECT_DATOS_dat/tabla_POSTS_IMAGENES/JPG00000.png". Esto no es HTML solo es la dirección URL donde un navegador cualquiera puede encontar la imagen. Para "colmo de males" JPG00000.png no es el campo #NAME o #ID de la imagen (que podriamos renombrar cuando quisieramos) si no que es la nomenglatura secuencial que Velneo le da al campo objeto #IMAGEN, nomenglatura que "no controlamos" y que es facilmente deducible.

Por lo tanto, mucho me temo que la solución lógicamente es la que apuntaba gegeo "si estando dentro de la DB se pueden ver, entonces, no las tengas dentro". Solucion que me desagrada profundamente por que tenerlas dentro de la DB aporta enormes ventajas, facilidades y rendimiento. Sacar las imagenes mas valiosas de la aplicación fuera de la BD me parece vergonzoso y un fiasco tremendo, que una vez mas tenemos que sortear no utilizando Veneo.

El protocolo VAPT protege perfectamente la privacidad de los datos, obligandonos a loguearnos para acceder a cualquier dato, lo que asegura el paso por "la caja" de Velneo, ¿por que se libera esta privacidad cuando se accede via http? No tiene sentido. Es un ENORME AGUJERO DE SEGURIDAD.

La solución provisional sería sencilla, "codificar de forma nativa la nomenglatura de objetos imagen Velneo" o "permitir el control en tiempo de ejecución de la accesibilidad de la imagen". Por supuesto pasará un buen tiempo hasta que esto ocurra, si algun dia llega a ocurrir.

Y como decia esa sería la solución provisional, por que la verdadera solución sería algo que me parece increible que nadie pida, y es que el vServer sirva HTML directamente. Ese si que seria un salto cualitativo de la herramienta y la verdadera apertura de la herramienta a la comunidad de desarrolladores, pero por ahora veo que estan mas centrados en dar rodeos con Javascript y el QML para solucionar las carencias que se deberian resolver de forma nativa.

8

@filipeagg,

Si lo poco que hace vModApache lo hiciera correctamente, se puede abordar cualquier proyecto serio. Es mas, mayoria de las herramientas orientadas al desarrollo HTML son incapaces de hacer lo que se puede hacer con la DB de Velneo.
Recurrir al PHP para montar paginas conectadas a una BD cuando Velneo tiene la arquitectura adecuada para poder hacerlo es una "amarga ironia del destino".¿Que le costaria a Velneo hacer que el vServer sirviera HTML de forma nativa? ¿Que le costaria implementar comandos nativos para la gestion de IP?, parece ser que ya seremos capaces de gestionar XML y ¿que faltaria para JSON?
Ojalá llegue el dia.

9

Que el vserver sirva directamente html, fue totalmente descartado por la comunidad hace unos años. Las ventajas del vmodapache son evidentes.

De todas las formas sigo sin entender porque reacionamos tan mal, el facto de incluir otros lenjuages o herramientas externas a velneo.

Una aplicación en c++ o .net tiene en la mayoria de los casos librerias externas al proyecto y al desarrollador, y nadie se lo ocurre decir a microsoft que inclua esta o otra funcionalidad de forma nativa (sin programación de bajo nivel).

En mi opinión el PHP aporta 100 veces más ventajas do que incovenientes a la hora de servir paginas web en velneo.
Ahora, claro está, para hacerlo bien y rápido hay que tener un minimo de conecimiento.

Para que tengais una idea, estoy desarrollando un mini cms en velneo, en que las paginas web las sirve PHP obteniendo datos de velneo, sin exagerar al momento actual tengo el nucleo operativo y he programado cerca de 50 lineas de codigo, pero tengo el total control en todos los aspectos de las entradas y salidas del flujo de datos, podiendo manipular estos datos en cualquier momento y desde el sitio que desee.

Yo he hecho y rehecho dezenas de proyectos web con velneo, antes de llegar a esta conclusón, y al dia de hoy tengo consciencia, que fue la mejor opción que he hecho.

10

@filipeagg, No dudo que hayas conseguido una buena solución, pero no es natural utilizar el interprete PHP para la base de datos cuando Velneo tiene sus propios comandos de instrucción para manejar la BD y montar la páginas.

P.D. Y por cierto, deberías saber que el que el vServer no sirva directamente HTML es una de las mayores espinas que tiene clavada el vArquitecto (por que es el paso más natural posible de la herramienta), "pero el no es solo quien decide por donde va la herramienta". A si que ya sabeis chicos A PEDIR Y SE OS DARÁ.

11

Bueno en fin, como el hilo lo empecé yo y me he desviado del tema un poco:
AGUJERO DE SEGURIDAD TREMENDO Y NO HAY SOLUCIÓN DESDE DENTRO DE LA BD!
:(

12

@ikonos

Estoy con ambos. Lo ideal en un mundo maravilloso de nubes de algodón, sería, tener ambos mundos. vModApache y que el mismo vServer sirviera web. Pero ésto, también acarrearía otra cosa más a desarrollar probar etc...
.
Además, habilitar que vServer sirva web, sería cuestión de pocos días. Primero, porque v6x ya lo hacía, y segundo, porque todos sabemos que un servidor web básico es sencillo de implementar con unas "pocas" líneas de código. Pero claro, entonces, querríamos más. Poder crear sitios virtuales, redirecciones, etc..etc...etc....y todo eso, ya lo hace Apache, y "es el mejor", entonces, para qué reinventar la rueda?
.
Entiendo que el departamento correspondiente habrá tenido sus razones para no hacerlo. Mejor tener un "connector" a Apache que permite hacerlo todo y más, que implementar un servidor básico en vServer.
.
Igualmente, debido a mi desconocimiento de v6x, y de vModApache, @ikonos que diferencia, habría, entre redirigir desde vModApache y servir web directamente desde Velneo? Además de comodidad obviamente. Si vServer sirviera web, accederías a los distintos procesos, pero, igualmente, ésto también puedes hacerlo, llamando desde una plantilla HTML a procesos que devuelvan la estructura no? Ilumíname por favor.

13

@Giuseppe,

Yo encuentro muchas, empezando por la integración y siguiendo con tener el control efectivo de los contenidos a servir (cosa que no hace vModApache por ejemplo con las imagenes o con XML o con respuestas JSON) pero la "más significativa y valiosa para mi" es el control de las peticiones IP al servidor. Si actualmente quisieras saber que IP esta realizando la peticion a tu Apache, o bien lees el registro log de Apache (cosa que es una patata) o bién utilizas PHP. Por que el vServer solo nos permite conocer la IP de los que se conectan "via vatp" no via "http". Y tener la información real de quien está atacando tu BD a traves de la web es "FUNDAMENTAL" ¿Te imaginas la cantidad de información que puedes recoger de los usuarios? IP, redireccionamientos, localización, etc. ¿Te imaginas una web en Velneo en la que pudieras registrar quien hace cada Click y de donde viene? Que cara pondrían tus clientes si les presentaras un informe inmediato de quien a accedido a su web y desde donde lo han hecho. ¿Que potencial de crecimiento tendria una empresa con una herramienta relacional con sus clientes de esta envergadura?
Imaginate una web con 1.000.000 de clicks al año en sus páginas ¿Crees que alguna empresa de publicidad querria pagarte por insertar publicidad si le demuestras quien y como se conectan a tu WEB?
¿Que complejidad tendria esta gestion en la DB de Velneo? Ninguna!
¿Que complejidad tendria integrar estas utilidades en el vServer? Muy poca!
¿Que beneficios aportaria a alguien emprendedor? Respondete tu mismo ;)

14

interesante discusión:

@ikonos a pesar de que soy de la posición de @filipe es bueno tener la mente abierta, tu ya tienes una solución caminando y tienes tus resultados, dos preguntas:

1. con respecto a lo de info de visitas hay algo que no te satisfaga de Google Analitycs para montarte algo propio ?, Apache + (Php, Phyton, Ruby, etc) +vModApache + Google Analytics me parece una adecuada segmentación, cada quien para lo que hace.

2. siguiendo tu ejemplo de 1.000.000 de visitas, en serio quieres que vServer lidie con todo eso ?, no afectaría el rendimiento de tu app para la parte interna de la empresa ?, no estaría tu app mas vulnerable a ataques ?, para mi el aislamiento del app es importantisimo.

un Saludo,

15

@cristianvg

1. por eso Google es lo que es, y vale lo que vale, por que tiene Google Analytics. ¿tienes tú algún problema en tener algo propio tan valioso?
2. ¿cuantos vServers tiene tu aplicación empresarial? ¿solo 1? ¿por que debes tener la parte WEB en el mismo? Es más ¿cuantos server debe tener tu WEB? ¿solo 1? Entonces no es de 1.000.000 de clicks.

P.D. En el soporte que he remitido para el problema de privacidad de las imagenes, Velneo me a sugerido utilizar el módulo de ReWrite de Apache, realizaré pruebas y ya os cometaré.

Saludos