NET: Encriptar secciones de web.config

22 11 2010

A menudo cuando desarrollamos aplicaciones Web (normalmente como extensiones de MSCRM) utilizamos el archivo web.config de la aplicación web para almacenar variables globales de la aplicaciones. Así por ejemplo, solemos añadir las cadenas de conexión a datos que posteriormente usaremos en la aplicación para conectar a bases de datos… Es muy importante saber que normalmente, el acceso al archivo web.config desde el navegador debe estar restringido pero, puede suceder que por alguna configuración ajena se permita este acceso. Por tanto, cualquier información que estemos añadiendo en este archivo de texto, puede comprometer la seguridad de nuestro sistema o puede estar ofreciendo al usuario información no deseada. En algunas instalaciones he llegado a ver que en este archivo se introduce incluso el password sin encriptar del usuario administrador de MSCRM!!!.

Figura 1. Error al acceder a web.config desde u navegador

Pues bien, además de intentar no introducir información clave en este archivo, si nos es necesario podemos optar por la opción de cifrar ciertas secciones de este archivo. Así por ejemplo, imaginad que tuviéramos definida una cadena de conexión a datos sobre la base de datos CRM en nuestro archivo web.config:


<connectionStrings>
<add name="strConn" connectionString="Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=MINHAC_MSCRM;Server=." />
</connectionStrings>

En este caso, la cadena de conexión no contiene usuario y password pues se utiliza la autenticación de Windows (la más recomendada en estos casos) para acceder al SQL Server). Sin embargo si trabajáramos con autenticación de SQL Server (poco recomendable) aparecería el usuario y la clave!!!.

Para encriptar esta sección y cifrar su contenido tan sólo necesitamos ejecutar un comando propio de NET Framework. Debemos situarnos en el directorio del NET Framework correspondiente a la aplicación Web (normalmente, si estamos en CRM 4.0, la versión de NET Framework es la 2.0) y ejecutar el siguiente comando:

Tras ejecutar este comando podremos observar que la sección connectionStrings de nuestro web.config ha sido encriptado:


<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData> <CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAA3I15yxfdeUywFzxPgNcnwwQAAAACAAAAAAADZgAAqAAAABAAAAB3OUG0nsxHtLh8yzBw6VtjAAAAAASAAACgAAAAEAAAAOSsEyXru5ZMGH6CC1uompVoAQAAsj8zgTP6NrsguTxVWPv0xm6Y04836QDdJ4r6yt/9XqN70ToMQABZqWnEnaSaqDDWIZaEEt/0OmJCxJXiedVomhKf2S0I+fMTBVLSLqj4pKaqSjlNjQgSfa+EoKZz5u7o3AxC4zhQS5TJ7nqdgIzIwe+upxfVUJpH0//m41u1rarWdrI/k3nUzlsvz3f7eiVyfsnk+PQ9QWXbWnIqPpFizAmGOcwbhWtk7AzT2VkMg2xdwZFYg4hpTXFYHqaU5XXocryrdHBxrj2zjE+h+4NURC3mmCd8NPEkpe2iGydJo75F1dHsuToGc9E3XRiDwHmB2dVXQkcNFxkdgS7Z6eRhJGdBVri5TYq6U1Gj8kIUe6g4CwkUnZaW8F3FjSWf3Lfl8KZLLG6OCBmwcyQEwUw06BVQah4KfKE8fHZHabI5EMWFaQ11ywsXs0YEJg+XdkHv+mUOocl3qAF+Y25GfYVgSm5JI5SyqvMHFAAAAJUDQ5kizMW2E+7oqVbIEhAbyUyK
</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>

Esta acción no requiere que en el código de la página ASP.NET en la que usemos esta cadena de conexión realicemos ninguna acción especial pues es el propio IIS el que realiza la encriptación y desencriptación y por tanto, al leer la cadena desde la págia ASPX, IIS ya realiza el descifrado.

Para recuperar el archivo original, tan sólo es necesario utilizar el mismo comando con otro parámetro:

Tan sólo hay que tener presente un par de cuestiones:

1. El cifrado depende de la máquina donde está instalado IIS por tanto, si tenemos dos entornos NO podemos copiar el archivo web.config con secciones cifradas de un servidor a otro pues en el nuevo no se interpretaría el cifrado. Debe ejecutarse el comando individualmente en ambos servidores

2. Existen dos tipos de cifrado (que indicamos en el parámetro –prov) que se pueden usar: DataProtectionConfiguratioProvider y RsaProtectionConfigurationProvider. Al desencriptar no es necesario indicar el proveedor pues ya se especifica en el archivo

Anuncios




ASP.NET: Declaración DOCTYPE y su efecto sobre el diseño de webforms

22 11 2010

Supongo que más de uno se habrá preguntado que significa o para que sirve el tag (o declaración) DOCTYPE que encontramos en los web form creados en Visual Studio. Tras crear un nuevo webform observaremos que se nos crea la siguiente declaración tras la directiva @Page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Pues bien, el tema tiene su miga! Para los más curiosos os recomiendo el link http://aspnetresources.com/articles/doctype.aspx donde se explica muy detalladamente el origen, significado y alguna que otra curiosidad al respecto. Pero el motivo de mi artículo no es el de explicar su significado o propósito (para eso ya hay páginas enteras). El motivo de este artículo es el comentaros una de las consecuencias una vez más de no prestar (o no tener suficiente tiempo para prestar…) atención a los que por defecto nos crea Visual Studio.

Ejemplo de webform creado en VS2008 SP1 (NET 2.0) donde se añade automáticamente el DOCTYPE

En esta ocasión tras haber creado muchas páginas ASP.NET en muchas integraciones de MSCRM he descubierto ( o mejor dicho, por fin he podido prestar atención!!!) los efectos de esa ‘inofensiva’ declaración DOCTYPE. Pues bien, los que tengáis paciencia o interesa por haber leído el link donde se describe la declaración DOCTYPE habréis comprendido, entre otras cosas, que esa declaración permite que la página tan sólo utilice objetos con compatibilidad sobre unas versiones de IE (no entraré en detalle). Pero, nunca hubiera imaginado que esa declaración afectaría al comportamiento de ciertos estilos o controles!!!

Uno de los temas en los que he dedicado más tiempo ha sido en poder crear un formulario web en el que el contenido de la página se redimensionara al variar el tamaño de la ventana. Una de las opciones que uno piensa en primer lugar és crear una tabla con altura y anchura 100%, ¿correcto?. Pues bien, si dejamos la declaración DOCTYPE que nos aparece al crear el web form, el atributo altura 100% (height en el style) NO funcionará! Por tanto, desde hace mucho tiempo he utilizado la solución del control panel y código JavaScript en los eventos onload y onresize para redimensionar el panel al cambiar las dimensiones de la ventana… Harto de ver en mil y un foros que la gente utilizaba el height 100%, me paré a investigar porqué a mí no me funcionaba y, finalmente, encontré la explicación en la declaración DOCTYPE.

Como conclusión, para poder utilizar todas las novedades del lenguaje HTML, así como las característica completas de JavaScript y, en definitiva, estar a la última, se debe eliminar la declaración DOCTYPE que añade Visual Studio al inicio de los nuevos web forms que creemos. Muy probablemente seguro que existe alguna cofiguración de VS para evitar que se cree esa declaración por defecto… si alguien la conoce o la encuentra, por favor, añadidlo en u comentarios a este artículo, gracias.

Resultado de mostrar una <table> con la dimensión height a 100% con la declaración DOCTYPE

El mismo código anterior pero sin la declaración DOCTYPE

Como observamos en el ejemplo, sin la declaración DOCTYPE la dimensión height: 100% actúa correctamente!!! Con lo cual es mucho más simple crear formularios autodimensionables sin la necesidad de usar código JavaScript para realizar la ubicación y dimensionado de los controles.

P.D.: No he entrado en mucho detalle sobre el entorno de programación… pero si creo que es importante destacar que esta situación la he encontrado creando formularios web con Visual Studio 2008 SP1 en proyectos con NET Framework 2.0 (probablemente con proyectos NET Framework 3.0 o 3.5 no ocurra esto).