none
¿es visible los datos de conexión ?

    Pregunta

  • ¡Hola!

    Estoy finalizando la primera versión de mi aplicación casi funcional ya,y me planteo la duda. Si la base de datos está en otro servidor, y la aplicación la instalo en diversos ordenadores de distintas clientes...... Todos van a acceder a la misma base de datos, la cadena de conexión está en el APP.CONFIG      ¿esa información puede ser interceptada o consultada de alguna forma y así algúien con no muy buenas intenciones acceder a mi base de datos y modificar cosas?.

    ¿como podría solucionar ese problema?. Que no se pueda ver datos de conexión.

    viernes, 6 de enero de 2017 8:46

Respuestas

  • ¿Existe algúna otra tecnología mas sencilla que un webService?.[...] NOTA2: Como tecnología de datos estoy usando EntityFramework 6

    Sí, hay una alternativa más sencilla: Usa un servicio WebApi2. Si estás trabajando con EF6, el WebApi se puede generar de forma automática desde Visual Studio sin que tengas que escribir a mano el código. Y desde el lado cliente puedes añadir un proxy que usa OData para comunicarse con el WebApi, y admite que uses LINQ de forma que desde el punto de vista de tu código cliente no tendrás que cambiar casi nada, funcionará casi igual que si estuvieses llamando a EF.
    si para cada usuario que desea acceso tengo que asignar permisos a los storeProc sería muy pesado.
    Hay una forma sencilla de hacerlo: Asigna los permisos a un rol, y luego cuando des de alta cada usuario (con CREATE LOGIN) hazlo miembro de ese mismo rol, con lo que no tienes que asignar los permisos uno a uno. Luego, el SP examina por dentro quién es el usuario y solo le devuelve los datos que le correspondan.
    sábado, 7 de enero de 2017 9:30

Todas las respuestas

  • Hola Carmelo:

    Entiendo que lo que planteas lo podemos resumir en dos situaciones, una es que el usuario pueda acceder a la cadena de conexión y otra es que pueda acceder a la base de datos. Lógicamente el que acceda a tu app.config no implica nada mas que pueda tocar algo y que después no le funcione la aplicación, otra muy distinta es que pueda abrir la base de datos conociendo su password. Bueno, centrándonos en esta última, lo que se suele hacer es encriptar la parte del password de dicha cadena, es decir, el password de acceso a tu base de datos. Con ello, tus usuarios ya no podrán acceder a tu base de datos, porque al final que conozcan o no la cadena de conexión que figura en el App.Config no conduce a nada.

    Resumiendo si que te diría que es necesario que encriptes dicha password y asunto solucionado.

    Tienes mucha información sobre diferentes métodos de encriptación: Has, etc. en internet., de cualquier forma si necesitas mas ayuda, nos la indicas.

    Un cordial saludo.

    Gemma

    viernes, 6 de enero de 2017 11:25
  • Si es una aplicación de escritorio y la cadena de conexión está en el .exe.config, el usuario siempre va a ser capaz de verla (si no fuese capaz de verla, como la aplicación se ejecuta con los permisos del usuario, la propia aplicación sería incapaz de ver la cadena de conexión).

    Se puede mitigar ligeramente el problema cifrando la cadena de conexión, como ya te han propuesto en otra respuesta anterior. Pero aunque esto dificulta ligeramente las cosas al usuario que quiera verla, no es una solución perfecta porque aunque la cadena esté cifrada, necesariamente la aplicación tiene que contener las claves y el algoritmo necesarias para descifrarla (sino no la podría usar). Por lo tanto, un usuario malicioso podría recuperar esos datos descompilando la aplicación o ejecutándola bajo un debugger.

    La única solución "buena" es que las claves de la base de datos no sean las mismas para cada usuario, sino que cada usuario tenga las suyas (que se configuran durante la instalación de la aplicación, o la aplicación las pregunta la primera vez que se ejecuta). Esas claves se pueden salvar dentro de los Settings de la aplicación, que solo son visibles por ese usuario y no por otros. O mejor todavía, si los puestos de trabajo pertenecen a una red corporativa, usar autenticación integrada (sin password, por lo que no hay que salvar nada).

    Evidentemente, esas claves personalizadas por usuario hay que irlas dando de alta en la base de datos, y los permisos internos de la base de datos solo deben permitir que con esos logins se acceda a los objetos de base de datos que ese usuario está legitimado para acceder, controlando aquellas cosas que el usuario puede o no puede hacer a nivel de base de datos, y no a nivel de aplicación cliente ya que ésta se la podrían saltar.

    viernes, 6 de enero de 2017 12:10
  • "Carmelo J. Morales Muñoz" preguntó:

    > Todos van a acceder a la misma base de datos, la cadena de conexión
    > está en el APP.CONFIG  ¿esa información puede ser interceptada o
    > consultada de alguna forma y así algúien con no muy buenas intenciones
    > acceder a mi base de datos y modificar cosas?.

    Hola, Carmelo J.:

    Por supuesto que puede ser consultada y editada por cualquier persona, por ejemplo, mediante el Bloc de Notas de Windows o cualquier otro editor de texto plano, con independencia que esa persona tenga o no muy buenas intenciones.

    > ¿como podría solucionar ese problema?. Que no se pueda ver datos de conexión.

    Cifrando la cadena de conexión completa en el archivo app.config:

    Cadenas de conexión y archivos de configuración

    Cifrar información de configuración mediante una configuración protegida

    Pero podríamos estar en las mismas, porque si utilizas un contenedor de claves RSA, también alguien con no muy buenas intenciones podría acceder a dicho contenedor. Y si lo encriptas todo mediante un algoritmo simétrico, necesitarás tener protegida la clave privada con la que encriptas/desencriptas el contenido de la cadena de conexión. Y ahora la pregunta sería, ¿dónde almacenas esa clave privada (una matriz máxima de 256 bits para los algoritmos AES o Rijndael) para que tampoco nadie pueda acceder a ella?

    > Si la base de datos está en otro servidor, y la aplicación la
    > instalo en diversos ordenadores de distintas clientes......

    Si eso es así, digo yo que será porque alguien te habrá encargado que así sea, y ese alguien tendrá diseñadas unas mínimas medidas de seguridad para que nadie ande a sus anchas por la oficina donde se encuentra físicamente el servidor, y por ende, la base de datos. Y otro tanto de lo mismo sucederá con aquellos puestos de trabajo que se conecten con el servidor, o ¿es que cualquiera que entre en esa oficina puede encender libremente el primer PC que se encuentre y conectarse a dicho servidor?

    Si en esa oficina se cumplen ciertas medidas de seguridad, y aparte tu aplicación permite auditar quién ha ejecutado esto o aquello en la base de datos, pues no tendrías mucho que preocuparte por los ACCESOS NO AUTORIZADOS, pero si no se cumplen ni una ni otra circunstancias, pues ... ¡Ya me comentarás lo que puede ocurrir! ;-)

    Un saludo

     


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.

    viernes, 6 de enero de 2017 12:40
    Moderador
  • Gracias por vuestras respuestas, veo que coincidís en lo básico, que los datos deberían estar cifrados pero que lo ideal sería autenticación integrada de windows.  Pero no puedo usar eso, os comento un poco mejor el escenario a ver:

    En principio, hice una aplicación similar hace algún tiempo, básciamente cuaqluier persona puede descargar la aplicación, desde la propia aplicación puede solicitar la creación de un usuario y contraseña.

    En la base de datos tengo una tabla principal USUARIOS donde está algo como:

    Id

    usuario

    password

    Lo que sucede es que las credenciales que el usuario usa (usuario, clave) no son las de la base de datos, pero claro, la aplicación hace consultas a la base de datos, modificaciones, altas, etc.......  Si ven que la cadena de conexión a la base de datos lleva: servidor, usuario, clave    podrían cargar un Sql Management Studio y acceder a la base de datos y consultar todo lo de esa base de datos , es decir, todo lo que pueda hacer el usuario de base de datos.    Yo a nivel de aplicación restrinjo lo que puede hacer el usuario a nivel de aplicación, consulto tabla de usuario y veo si puede borrar, etc....    Lo que tengo que tener protegido es la cadena de conexión a la base de datos. ese usuario y clave son los peligrosos.

    Anteriormente en una aplicación menos compleja todo se hacía a travez de un webService. pero se hacía pesado, programar todo por dos veces.

    La idea es publicar la base de datos en Azure, para que esté accesible desde cualquier punto.

    No puedo restringir por IP.

    Entiendo que lo ideal sería una aplicación web pero es muy compleja para hacerla en web, necesito que sea de escritorio y en su defecto tal vez una versión para dispositivo mobil.

    esa es la idea. por si me podeis reorientar....

    un saludo

    viernes, 6 de enero de 2017 12:56
  • La idea que tienes es arriesgadísima desde el punto de vista de la seguridad. Con toda certeza, se te van a colar los "hackers". Aunque encriptes la cadena de conexión, cualquier hacker que se precie sabe "debuguear" la aplicación e interceptar la contraseña en el punto en el que ya ha sido desencriptada. Así que si quieres que esto tenga una mínima seguridad, no basta con que tengas una tabla de usuarios y claves y controles desde ahí el usuario. En lugar de ella (o además de ella) tienes TAMBIÉN que crear distintos logins en SQL Server, y a cada uno de tus usuarios asignarle uno de esos Logins, y controlar los permisos en la lógica del servidor (por ejemplo, usando procedimientos almacenados y no dándoles permisos sobre las tablas sino solo sobre los procedimientos). No es suficiente con que se controle desde la aplicación qué es lo que puede hacer cada usuario.

    Si no puedes hacer eso, entonces definitivamente la aplicación no será segura y alguien acabará colándose en la base de datos a pesar de que cifres la cadena de conexión. Siendo así las cosas, tendrías que cambiar la aplicación de escritorio por una aplicación web (o interponer un servicio web). Ya has comentado que esto te resulta lento y trabajoso, lo que hay que evaluar es si te resulta más trabajoso que rehacer el control de funcionalidad para que se verifique dentro de SQL en lugar de en el programa cliente. Pero una de las dos cosas hay que hacerla aunque cueste trabajo. De lo contrario, antes o después alguien terminará por acceder directamente a tu base de datos.

    viernes, 6 de enero de 2017 16:02
  • Muchas Gracias!....

    Tengo claro que he iniciado mal el planteamiento de comunicación con la base de datos, ahora que la aplicación está finalizada toca modificar lo que sea necesario para hacerla segura.

    Me estoy planteando usar SebServices. pero veo un inconveniente, si quiero traer una cantidad de información importante como por ejemplo un listado de artículos y el listado es "extenso" suele "fallar" debido a que suele haber restricciones (mi antiguo servidor ASP.net me obligó a bajar la información en bloques muy pequeños).

    Como he comentado antes, quiero publicar en Azure la base de datos,  supongo que por lo que veo me brinda posibilidad de crear también un servicio web.  pero.... ¿Existe algúna otra tecnología mas sencilla que un webService?.

    NOta: No me es viable asignar permisos para cada nuevo usuario, como he comentado los usuarios pedirán una cuenta y simplemente lo validaré, si para cada usuario que desea acceso tengo que asignar permisos a los storeProc sería muy pesado.

    ¿Se os ocurre alguna forma sencilla de acceder a la información para "x" usuarios que pueden ir cambiando constantemente sin comprometer la seguridad? (aparte del webService).  

    NOTA2: Como tecnología de datos estoy usando EntityFramework 6

    viernes, 6 de enero de 2017 17:51
  • ¿Existe algúna otra tecnología mas sencilla que un webService?.[...] NOTA2: Como tecnología de datos estoy usando EntityFramework 6

    Sí, hay una alternativa más sencilla: Usa un servicio WebApi2. Si estás trabajando con EF6, el WebApi se puede generar de forma automática desde Visual Studio sin que tengas que escribir a mano el código. Y desde el lado cliente puedes añadir un proxy que usa OData para comunicarse con el WebApi, y admite que uses LINQ de forma que desde el punto de vista de tu código cliente no tendrás que cambiar casi nada, funcionará casi igual que si estuvieses llamando a EF.
    si para cada usuario que desea acceso tengo que asignar permisos a los storeProc sería muy pesado.
    Hay una forma sencilla de hacerlo: Asigna los permisos a un rol, y luego cuando des de alta cada usuario (con CREATE LOGIN) hazlo miembro de ese mismo rol, con lo que no tienes que asignar los permisos uno a uno. Luego, el SP examina por dentro quién es el usuario y solo le devuelve los datos que le correspondan.
    sábado, 7 de enero de 2017 9:30