Proteger el acceso a datos

Artículo
10/22/2014

Actualización: noviembre 2007

La mayoría de las aplicaciones Web ASP.NET implican el acceso a datos. Muchas aplicaciones recogen datos para almacenarlos en una base de datos o en un archivo y, a menudo, se basan en información procedente de los usuarios. Puesto que los datos originales pueden proceder de orígenes que no son de confianza (ya que la información se almacena en un formato permanente) y hay que asegurarse de que los usuarios no autorizados no puedan obtener acceso al origen de datos directamente, es necesario prestar especial atención a los problemas de seguridad relacionados con el acceso a datos. La información de este tema describe los procedimientos recomendados para mejorar la seguridad del acceso a datos en las aplicaciones Web ASP.NET.

Aunque se puede mejorar la seguridad de la aplicación siguiendo las buenas prácticas en materia de codificación y configuración, también es importante mantener actualizado el servidor Web con las últimas actualizaciones de seguridad de Microsoft Windows e Internet Information Services (IIS), así como las actualizaciones de seguridad de Microsoft SQL Server o cualquier otro software de base de datos.

Puede encontrar información más detallada sobre los procedimientos recomendados para escribir código seguro y para proteger las aplicaciones en el libro "Writing Secure Code" de Michael Howard y David LeBlanc, o a través de las directrices incluidas en Microsoft Patterns and Practices.

Proteger el acceso a un origen de datos

Las secciones siguientes proporcionan información sobre cómo ayudar a proteger diferentes aspectos del acceso a datos.

Cadenas de conexión

Para conectar con una base de datos, se necesita una cadena de conexión. Puesto que las cadenas de conexión pueden contener datos confidenciales, se deben seguir estas instrucciones:

No almacene cadenas de conexión en ninguna página. Por ejemplo, evite la configuración de las cadenas de conexión como propiedades declarativas del control SqlDataSource o de otros controles de origen de datos. En su lugar, almacénelas en el archivo Web.config del sitio. Para obtener un ejemplo, vea Cómo: Proteger cadenas de conexión al utilizar controles de origen de datos.
No almacene cadenas de conexión como texto sin formato. Para proteger la conexión al servidor de base de datos, se recomienda cifrar la información de la cadena de conexión del archivo de configuración mediante la configuración protegida. Para obtener más información, vea Cifrar información de configuración mediante una configuración protegida.

Conectar con SQL Server mediante seguridad integrada

Si es posible, conéctese a una instancia de SQL Server utilizando la seguridad integrada en lugar de un nombre de usuario explícito y una contraseña. De esta forma, se evita la posibilidad de comprometer la integridad de la cadena de conexión y de exponer el identificador de usuario y la contraseña.

Se recomienda que se asegure de que la identidad del proceso (por ejemplo, la agrupación de aplicaciones) que está ejecutando ASP.NET sea la cuenta de proceso predeterminada o una cuenta de usuario restringida. Para obtener más información, vea Suplantación de ASP.NET.

En los casos en los que distintos sitios Web conectan con diversas bases de datos de SQL Server, puede que no resulte práctico utilizar la seguridad integrada. Por ejemplo, en los sitios de alojamiento Web, se suele asignar a cada cliente una base de datos de SQL Server diferente, pero todos utilizan el servidor Web como usuarios anónimos. En estos casos, debe utilizar credenciales explícitas para conectarse a una instancia de SQL Server. Asegúrese de almacenar las credenciales de forma segura, como se describe en este tema en Cadenas de conexión.

Permisos de base de datos de SQL Server

Se recomienda asignar los privilegios mínimos al identificador de usuario que se utiliza para la conexión a las bases de datos de SQL Server usadas en la aplicación.

Restringir las operaciones de SQL

Los controles enlazados a datos pueden admitir una gran variedad de operaciones con datos como selección, inserción, eliminación y actualización de registros en las tablas de datos. Se recomienda configurar los controles de datos para realizar la funcionalidad mínima necesaria de la página o aplicación. Por ejemplo, si un control no debe permitir a los usuarios que eliminen datos, no incluya una consulta Delete con un control de origen de datos y no permita eliminación en el control.

SQL Server Express

Para asociar un proceso a una base de datos de SQL Server Express (archivo .mdf), debe tener permisos de administrador. En general, esta es la razón por la que las bases de datos de SQL Server Express no son prácticas para la creación de sitios Web, ya que el proceso de ASP.NET no se ejecuta (ni se debe ejecutar) con privilegios administrativos. Por consiguiente, utilice las bases de datos de SQL Server Express sólo en los siguientes casos:

Como base de datos de prueba al desarrollar la aplicación Web. Cuando esté listo para implementar la aplicación, puede transferir la base de datos de SQL Server Express a una instancia de producción de SQL Server.
Utilícelas si está ejecutando un sitio Web que permite la suplantación y puede controlar los privilegios del usuario suplantado. En la práctica, esta estrategia es conveniente si la aplicación se está ejecutando en una red de área local (no en un sitio Web público).
Almacene el archivo .mdf en la carpeta App_Data del sitio porque el contenido de la carpeta no se devolverá para enviar solicitudes HTTP. También debe asignar la extensión .mdf a ASP.NET en IIS y al controlador HttpForbiddenHandler en ASP.NET mediante el siguiente elemento en el archivo Web.config del sitio:
```
<httpHandlers>
  <add verb="*" path="*.mdf" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Para obtener información sobre cómo asignar una extensión de nombre de archivo a ASP.NET en IIS, vea Cómo: Registrar controladores HTTP.

Bases de datos de Microsoft Access

Las bases de datos de Microsoft Access (archivos .mdb) incluyen menos características de seguridad que las de SQL Server. No se recomienda utilizar bases de datos de Access para la creación de sitios Web. Sin embargo, si por alguna razón tiene que utilizar un archivo .mdb como parte de la aplicación Web, siga estas instrucciones:

Almacene el archivo .mdb en la carpeta App_Data del sitio porque el contenido de la carpeta no se devolverá ante solicitudes HTTP directas. También debe asignar la extensión .mdb a ASP.NET en IIS y al controlador HttpForbiddenHandler en ASP.NET mediante el siguiente elemento en el archivo Web.config del sitio:
```
<httpHandlers>
  <add verb="*" path="*.mdb" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Para obtener información sobre cómo asignar una extensión de nombre de archivo a ASP.NET en IIS, vea Cómo: Registrar controladores HTTP.
Agregue los permisos adecuados a las cuentas de los usuarios que leerán el archivo .mdb y escribirán en él. Si el sitio Web admite el acceso anónimo, ésta suele ser la cuenta de usuario ASPNET local o la cuenta NETWORK SERVICE. Dado que Access debe crear un archivo .ldb para admitir el bloqueo, la cuenta de usuario debe tener permisos de escritura para la carpeta que contiene el archivo .mdb.
Si la base de datos está protegida con contraseña, no utilice el control AccessDataSource para establecer una conexión con ella, ya que AccessDataSource no admite el paso de credenciales. En su lugar, utilice el control SqlDataSource con el proveedor ODBC y pase las credenciales en la cadena de conexión. Asegúrese de proteger la cadena de conexión como se describe en este tema en Cadenas de conexión.

Archivos XML

Si está almacenando datos en un archivo XML, coloque el archivo en la carpeta App_Data del sitio Web porque el contenido de la carpeta no se devolverá como respuesta a solicitudes HTTP directas.

Protegerse de los datos de entrada malintencionados

Si la aplicación acepta la entrada de datos de los usuarios, debe asegurarse de que su contenido no es malintencionado y no compromete la integridad de la aplicación. Los usuarios malintencionados pueden introducir datos para iniciar los siguientes ataques:

Inyección de secuencia de comandos Un ataque de inyección consiste en enviar una secuencia de comandos a la aplicación para que otros usuarios la ejecuten. En los ataques de inyección típicos, las secuencias de comandos se envían a una página que las almacena en una base de datos, de modo que otro usuario que vea los datos ejecute el código sin darse cuenta.
Inyección SQL Los ataques de inyección SQL intentan comprometer la seguridad de la base de datos, y posiblemente la del equipo en el que se está ejecutando, creando comandos de SQL que se ejecutan sustituyendo o sumándose a los integrados en la aplicación.

Instrucciones generales

Para todos los datos proporcionados por los usuarios, siga estas instrucciones:

Utilice controles de validación siempre que sea posible para admitir sólo valores aceptables.
Asegúrese de que el valor de la propiedad IsValid es true antes de ejecutar su código del servidor. Un valor de false significa que uno o más controles de validación han producido un error en una comprobación de validación.
Realice siempre validaciones en el servidor aunque el explorador también las esté realizando para protegerse contra los usuarios que omiten la validación en el cliente, especialmente para los controles CustomValidator; no utilice sólo la lógica de validación del cliente.
Vuelva a validar siempre los datos proporcionados por los usuarios en la capa de negocio de la aplicación. No confíe en el proceso de llamada para proporcionar datos seguros. Por ejemplo, si utiliza el control ObjectDataSource, agregue validación y codificación redundantes al objeto que realiza las actualizaciones de los datos.

Inyección de secuencia de comandos

Para evitar los ataques de inyección de secuencia de comandos, siga estas instrucciones:

Codifique la entrada del usuario con el método HtmlEncode, que convierte el código HTML en su representación de texto (por ejemplo, <b> se vuelve &ltb>) y ayuda a evitar que el marcado se ejecute en un explorador.
Al utilizar objetos de parámetro para pasar los datos proporcionados por el usuario a una consulta, agregue controladores para los eventos previos a la consulta del control de origen de datos y lleve a cabo la codificación en esos eventos. Por ejemplo, controle el evento SqlDataSource del control Inserting y, en el evento, codifique el valor del parámetro antes de que se ejecute la consulta.
Si va a utilizar el control GridView con campos enlazados, establezca la propiedad BoundField del objeto HtmlEncode en true. De esta forma, el control GridView codifica los datos proporcionados por los usuarios cuando la fila está en modo de edición.
Para los controles que se pueden colocar en el modo de edición, se recomienda utilizar plantillas. Por ejemplo, los controles GridView, DetailsView, FormView, DataList y Login pueden mostrar cuadros de texto modificable. Sin embargo, salvo el control GridView (vea el punto anterior), los controles no validan automáticamente ni codifican en HTML los datos proporcionados por los usuarios. Por consiguiente, se recomienda crear plantillas para estos controles e incluir en ellas un control de entrada como TextBox y agregar un control de validación. Además, al extraer el valor del control, debe codificarlo.

Inyección SQL

Para evitar los ataques de inyección SQL, siga estas instrucciones:

No cree comandos de SQL concatenando las cadenas, sobre todo las que incluyen datos introducidos por los usuarios. Utilice consultas con parámetros o procedimientos almacenados.
Si crea una consulta parametrizada, utilice objetos de parámetro para establecer los valores de los parámetros. Para obtener información detallada, vea Utilizar parámetros con el control SqlDataSource y Utilizar parámetros con controles de origen de datos.

Cifrar datos de estado de vista

A veces, los controles enlazados a datos, como el control GridView, deben conservar información que se considera confidencial. Por ejemplo, este control puede mantener una lista de claves en la propiedad DataKeys, aunque no se muestre esta información. Entre las acciones de ida y vuelta, el control almacena la información en el estado de vista.

La información del estado de vista se codifica y almacena con el contenido de la página y se podría descodificar y exponer a un origen no deseado. Si debe almacenar información confidencial en el estado de vista, puede solicitar que la página cifre los datos del estado de vista. Para cifrar los datos, establezca la propiedad ViewStateEncryptionMode de la página en true.

Almacenamiento en caché

Se recomienda no almacenar información confidencial en el objeto Cache cuando la suplantación del cliente esté habilitada y los resultados del origen de datos se recuperen en función de la identidad del cliente. Si el almacenamiento en caché está habilitado, todos los usuarios pueden ver los datos almacenados en caché para un único usuario y es posible que se exponga información importante a una fuente no deseada. La suplantación del cliente está habilitada cuando el atributo impersonate del elemento de configuración identidad está establecido en true y la identificación anónima está deshabilitada para la aplicación en el servidor Web.

Compartir a través de