Consideraciones de seguridad (Entity Framework)

  • Artículo

En este tema se describen consideraciones de seguridad que son específicas del desarrollo, implementación y ejecución de aplicaciones de Entity Framework. También debe seguir las recomendaciones para crear aplicaciones de .NET Framework seguras. Para más información, consulte Introducción a la seguridad.

Consideraciones generales de seguridad

Las consideraciones de seguridad siguientes se aplican a todas las aplicaciones que utilizan Entity Framework.

Usar solo proveedores de orígenes de datos de confianza.

Para comunicarse con el origen de datos, un proveedor debe hacer lo siguiente:

  • Reciba la cadena de conexión de Entity Framework.

  • Traducir el árbol de comandos al lenguaje de consultas nativo del origen de datos.

  • Ensamblar y devolver los conjuntos de resultados.

Durante la operación de inicio de sesión, la información que se basa en la contraseña del usuario se pasa al servidor a través de las bibliotecas de red del origen de datos subyacente. Un proveedor malintencionado puede robar las credenciales del usuario, generar consultas malintencionadas o alterar el conjunto de resultados.

Cifrar la conexión para proteger los datos confidenciales.

Entity Framework no administra el cifrado de datos directamente. Si los usuarios tienen acceso a los datos a través de una red pública, la aplicación debería establecer una conexión cifrada al origen de datos para aumentar la seguridad. Para obtener más información, consulte la documentación relacionada con la seguridad correspondiente al origen de datos. Para un origen de datos de SQL Server, vea Cifrar las conexiones a SQL Server.

Proteger la cadena de conexión.

La protección del acceso al origen de datos es uno de los objetivos más importantes a la hora de proteger una aplicación. Una cadena de conexión presenta una vulnerabilidad potencial si no se protege o si se construye incorrectamente. Al almacenar la información de conexión en texto sin formato o conservarla en la memoria, se pone en riesgo todo el sistema. A continuación se enumeran métodos recomendados para proteger las cadenas de conexión:

  • Utilice la autenticación de Windows con un origen de datos de SQL Server.

    Al utilizar la autenticación de Windows para conectarse a un origen de datos de SQL Server, la cadena de conexión no contiene información de contraseñas ni del inicio de sesión.

  • Cifre las secciones del archivo de configuración mediante una configuración protegida.

    ASP.NET incluye una característica denominada configuración protegida, que permite cifrar la información confidencial en un archivo de configuración. Si bien se ha diseñado principalmente para ASP.NET, la configuración protegida también puede usarse para cifrar secciones de los archivos de configuración en aplicaciones Windows. Para obtener una descripción detallada de las nuevas funciones de configuración protegida, vea Cifrar información de configuración mediante una configuración protegida.

  • Almacene las cadenas de conexión en archivos de configuración protegidos.

    Nunca debería incrustar las cadenas de conexión en el código fuente. Las cadenas de conexión también se pueden almacenar en archivos de configuración, lo que elimina la necesidad de incrustarlas en el código de la aplicación. De forma predeterminada, el Asistente para Entity Data Model almacena las cadenas de conexión en el archivo de configuración de la aplicación. Debe proteger este archivo para evitar el acceso no autorizado.

  • Utilice generadores de cadenas de conexión al crear dinámicamente las conexiones.

    Si debe construir las cadenas de conexión en tiempo de ejecución, utilice la clase EntityConnectionStringBuilder. Esta clase de generador de cadenas ayuda a evitar los ataques de inyección en las cadenas de conexión validando y anulando la información de entrada no válida. Para obtener más información, vea Cómo: Compilar una cadena de conexión EntityConnection. Utilice igualmente la clase de generador de cadenas adecuada para construir la cadena de conexión a un origen de datos que forme parte de la cadena de conexión de Entity Framework. Para obtener información sobre los generadores de cadenas de conexión para los proveedores de ADO.NET, vea Generadores de cadenas de conexión.

Para más información, consulte Proteger la información de conexión.

No exponga EntityConnection a usuarios que no sean de confianza.

Un objeto EntityConnection expone la cadena de conexión de la conexión subyacente. Un usuario con acceso a un objeto EntityConnection también puede cambiar el ConnectionState de la conexión subyacente. La clase EntityConnection no es segura para la ejecución de subprocesos.

No pase las conexiones fuera del contexto de seguridad.

Una vez establecida una conexión, no debe pasarla fuera del contexto de seguridad. Por ejemplo, un subproceso con permiso para abrir una conexión no debería almacenar la conexión en una ubicación global. Si la conexión está disponible en una ubicación global, otro subproceso malintencionado puede utilizar la conexión abierta sin que se le haya concedido ese permiso explícitamente.

Sea consciente de que la información de inicio de sesión y de contraseñas puede estar visible en un volcado de memoria.

Cuando la información de contraseñas y del inicio de sesión del origen de datos se proporciona en la cadena de conexión, se mantiene en la memoria hasta que la recolección de elementos no utilizados reclama los recursos. Esto impide determinar el momento en que una cadena de contraseña deja de estar en la memoria. Si una aplicación se bloquea, un archivo de volcado de memoria puede contener información de seguridad importante y el usuario que ejecuta la aplicación y cualquier usuario con acceso administrativo al equipo puede ver dicho archivo. Utilice la autenticación de Windows para las conexiones con Microsoft SQL Server.

Conceda a los usuarios únicamente los permisos necesarios en el origen de datos.

Los administradores de orígenes de datos solo deberían conceder a los usuarios los permisos que necesitan. Aunque Entity SQL no admite las instrucciones DML que modifican datos, como INSERT, UPDATE o DELETE, los usuarios todavía pueden tener acceso a la conexión al origen de datos. Un usuario malintencionado podría utilizar esta conexión para ejecutar instrucciones DML en el lenguaje nativo del origen de datos.

Ejecute las aplicaciones con los permisos mínimos.

Al permitir que una aplicación administrada se ejecute con permiso de plena confianza, .NET Framework no limita el acceso de la aplicación al equipo. De esta forma se puede permitir que una vulnerabilidad de seguridad en la aplicación ponga en peligro a todo el sistema. Para utilizar la seguridad de acceso del código y otros mecanismos de seguridad en .NET Framework, debería ejecutar las aplicaciones utilizando permisos de confianza parcial y con el conjunto mínimo de permisos que se necesitan para permitir que la aplicación funcione. Los permisos de acceso a código siguientes son los permisos mínimos que una aplicación de Entity Framework necesita:

Para obtener más información, consulta Code Access Security and ADO.NET.

No instale aplicaciones que no sean de confianza.

Entity Framework no exige ningún permiso de seguridad e invocará cualquier código de objeto de datos proporcionado por el usuario en proceso con independencia de si es de confianza o no. Asegúrese de que la autenticación y la autorización del cliente se llevan a cabo en el almacén de datos y en la aplicación.

Restrinja el acceso a todos los archivos de configuración.

Un administrador debe restringir el acceso de escritura a todos los archivos que especifican la configuración para una aplicación, incluidos enterprisesec.config, security.config, machine.conf y el archivo de configuración de la aplicación <application>.exe.config.

El nombre invariable del proveedor se puede modificar en app.config. La aplicación cliente debe asumir la responsabilidad del acceso al proveedor subyacente a través del modelo de fábrica de proveedor estándar utilizando un nombre seguro.

Restrinja los permisos a los archivos de asignación y de modelo.

Un administrador debe restringir el acceso de escritura a los archivos de asignación y de modelo (.edmx, .csdl, .ssdl y .msl) únicamente a los usuarios que modifican el modelo o las asignaciones. Entity Framework sólo requiere acceso de lectura a estos archivos en tiempo de ejecución. Un administrador debería restringir también el acceso al nivel de objetos y a los archivos para ver código fuente precompilados que generan las herramientas de Entity Data Model.

Consideraciones de seguridad para las consultas

Se deben tener en cuenta las consideraciones de seguridad siguientes cuando se consulta un modelo conceptual. Estas consideraciones se aplican a las consultas de Entity SQL que usan EntityClient y en las consultas de objetos que usan LINQ, los métodos del generador de consultas o Entity SQL.

Impida los ataques de inyección de SQL.

A menudo, las aplicaciones obtienen entradas externas (de un usuario o de otro agente externo) y realizan acciones en función de dichas entradas. Cualquier entrada derivada directa o indirectamente del usuario o de un agente externo puede inyectar contenido que aproveche la sintaxis del lenguaje de destino para realizar acciones no autorizadas. Cuando el lenguaje de destino es del tipo de Lenguaje de consulta estructurado (SQL), como Transact-SQL, esta manipulación se conoce como ataque de inyección de SQL. Un usuario malintencionado puede inyectar comandos directamente en la consulta y colocar una tabla de la base de datos, provocar un ataque de denegación de servicio o cambiar de alguna otra forma la naturaleza de la operación que se está realizando.

  • Ataques de inyección de Entity SQL:

    Los ataques de inyección de SQL se pueden realizar en Entity SQL proporcionando entradas malintencionadas a los valores que se utilizan en un predicado de consulta y en los nombres de los parámetros. Para evitar el riesgo de inyección de SQL, nunca debería combinar los datos proporcionados por el usuario con el texto de comandos de Entity SQL.

    Las consultas de Entity SQL aceptan parámetros siempre que se aceptan literales. Se deben usar consultas parametrizadas en lugar de insertar literales directamente en la consulta procedentes de un agente externo. Considere también la posibilidad de usar métodos del generador de consultas para construir Entity SQL sin ningún riesgo.

  • Ataques por inyección de LINQ to Entities:

    Aunque en LINQ to Entities se admite la composición de consultas, se lleva a cabo a través de la API del modelo de objetos. A diferencia de las consultas de Entity SQL, las consultas de LINQ to Entities no se crean mediante la manipulación ni la concatenación de cadenas y no son susceptibles a los ataques de inyección de SQL tradicionales.

Evite los conjuntos de resultados muy grandes.

Un conjunto de resultados muy grande podría hacer que el sistema cliente se cerrara si el cliente realizara operaciones que consumieran recursos en proporción al tamaño del conjunto de resultados. Los conjuntos de resultados inesperadamente grandes se pueden producir en las condiciones siguientes:

  • En consultas con una base de datos grande que no incluyen las condiciones de filtro adecuadas.

  • En consultas que crean combinaciones cartesianas en el servidor.

  • Crear consultas anidadas de Entity SQL.

Al aceptar datos proporcionados por el usuario, debe asegurarse de que no puedan provocar que los conjuntos de resultados se vuelvan mayores de lo que el sistema puede administrar. También puede utilizar el método Take de LINQ to Entities o el operador LIMIT de LINQ to Entities para limitar el tamaño del conjunto de resultados.

Evitar devolver resultados de IQueryable al exponer métodos a autores de llamadas que pueden no ser de confianza.

Evite devolver tipos IQueryable<T> desde métodos expuestos a autores de llamadas que pueden no ser de confianza por las siguientes razones:

  • Un consumidor de una consulta que expone un tipo IQueryable<T> podría llamar a métodos sobre el resultado que exponen datos seguros o aumenta el tamaño del conjunto de resultados. Por ejemplo, considere la siguiente firma de método:

    public IQueryable<Customer> GetCustomer(int customerId)

    Un consumidor de esta consulta podría llamar a .Include("Orders") sobre el IQueryable<Customer> devuelto para recuperar datos que la consulta no pretendía exponer. Esto se puede evitar cambiando el tipo de valor devuelto del método a IEnumerable<T> y llamando a un método (como .ToList()) que materialice los resultados.

  • Puesto que las consultas IQueryable<T> se ejecutan al iterar sobre los resultados, un consumidor de una consulta que expone un tipo IQueryable<T> podría interceptar las excepciones que se producen. Las excepciones podrían contener información no destinada para el consumidor.

Consideraciones de seguridad para entidades

Al generar y trabajar con tipos de entidad se aplican las consideraciones de seguridad siguientes.

No comparta un ObjectContext a través de dominios de aplicación.

Al compartir un ObjectContext con más de un dominio de aplicación, se puede exponer información en la cadena de conexión. En su lugar, debería transferir objetos serializados o gráficos de objetos al otro dominio de aplicación y, a continuación, asociar esos objetos a ObjectContext en ese dominio de aplicación. Para obtener más información, consulte Serializar objetos.

Evite las infracciones de seguridad de los tipos.

Si se infringe la seguridad de los tipos, Entity Framework no puede garantizar la integridad de los datos de los objetos. Se podrían producir infracciones de seguridad de tipos si permite que las aplicaciones que no son de confianza se ejecuten con seguridad de acceso del código de plena confianza.

Controle las excepciones.

Obtenga acceso a los métodos y propiedades de un ObjectContext dentro de un bloque try-catch. La detección de excepciones evita que las excepciones no controladas expongan las entradas del ObjectStateManager o la información del modelo (tal como nombres de las tablas) a los usuarios de la aplicación.

Consideraciones de seguridad para las aplicaciones ASP.NET

Debe tener en cuenta lo siguiente al trabajar con rutas de acceso en aplicaciones de ASP.NET.

Compruebe si el host realiza comprobaciones de la ruta de acceso.

Cuando se utiliza la cadena de substitución |DataDirectory| (incluida entre barras verticales), ADO.NET comprueba que la ruta de acceso resuelta se admite. Por ejemplo, ".." no se admite detrás de DataDirectory. El proceso que hospeda ~ realiza esa misma comprobación para resolver el operador de raíz de aplicación web (ASP.NET). IIS realiza esta comprobación; sin embargo, los hosts que no sean IIS pueden no comprobar que la ruta de acceso resuelta se admite. Debería conocer el comportamiento del host en el que implementa una aplicación de Entity Framework.

No haga suposiciones sobre los nombres de ruta resueltos.

Aunque los valores en los que se resuelven el operador raíz (~) y la cadena de sustitución DataDirectory deberían seguir siendo constantes durante la ejecución de la aplicación, Entity Framework no impide que el host los modifique.

Compruebe la longitud de la ruta de acceso antes de la implementación.

Antes de implementar una aplicación de Entity Framework, debería asegurarse de que los valores del operador de raíz (~) y la cadena de substitución DataDirectory no superan los límites de la longitud de la ruta de acceso del sistema operativo. Los proveedores de datos de ADO.NET no garantizan que la longitud de la ruta de acceso esté dentro de los límites válidos.

Consideraciones de seguridad de los metadatos de ADO.NET

Al generar y trabajar con los archivos de asignación y de modelo, se aplican las consideraciones de seguridad siguientes.

No exponga información confidencial a través del registro.

Los componentes del servicio de metadatos de ADO.NET no registran ninguna información personal. Si hay resultados que no se pueden devolver debido a las restricciones de acceso, los sistemas de administración de bases de datos y los sistemas de archivos no deberían devolver ningún resultado en lugar de generar una excepción que podría contener información confidencial.

No acepte objetos MetadataWorkspace de orígenes que no sean de confianza.

Las aplicaciones no deberían aceptar instancias de la clase MetadataWorkspace de orígenes que no sean de confianza. En su lugar, debería construir y rellenar explícitamente un área de trabajo de este tipo de origen.

Consulte también