Esta es una cuestión bastante habitual y es que es muy útil, siendo administrador de una aplicación, poder entrar como cualquier otro usuario para ver lo mismo que éste ve y poder hacer cosas en su nombre. Sobre todo a la hora de dar soporte técnico, poder atender mejor a los usuarios, ayudarles o detectar posibles problemas en sus cuentas.

La idea es la de poder entrar haciéndonos pasar por otros usuarios, como si fuésemos ellos, pero sin conocer sus credenciales. El otro día un alumno de mi curso de Desarrollo Web con ASP.NET me preguntó  precisamente esto, por lo que me he decidido a grabar un vídeo práctico explicando como hacerlo.

Como verás es muy fácil, pero interesante. Dejo el vídeo a continuación y te recomiendo que, antes, te leas este post que escribí hace tiempo sobre el funcionamiento de las cookies de autenticación.

¡Espero que te resulte útil!

Nota: Si el vídeo no se ve vete directamente al original aquí.

Existen una serie de ajustes en aplicaciones Web que deberíamos cuidar especialmente cuando las despleguemos en un servidor en producción. Se trata de características que, de estar mal establecidas en un servidor abierto a cualquiera a través de Internet, pueden suponer un problema de seguridad o mermar el rendimiento de una aplicación.

En este artículo vamos a estudiar dos de estos ajustes críticos, lo que suelen hacer mal los programadores con ellos y cómo podemos forzar su correcto uso en servidores de producción.

Depuración

Cuando estamos desarrollando una aplicación Web con ASP.NET (tanto Web Forms como MVC) establecemos una serie de configuraciones que nos facilitan la depuración de las mismas: mensajes de error detallados, depuración paso a paso, trazas del código, etc…

Existe un ajuste en la configuración de la aplicación Web (archivo web.config) que controla de manera global el estado de depuración y, por tanto, todas estas características:

<compilation debug=”true”/>

Es más, cuando lanzamos por primera vez una aplicación Web desde Visual Studio pulsando F5, se nos muestra una ventana de confirmación para establecer de manera automática este ajuste y que funcionen todas las características de depuración:

Al aceptar la opción por defecto se establece este ajuste automáticamente por nosotros:

Aunque está muy bien mientras desarrollamos, se trata de algo inaceptable en un servidor en producción, una vez que la aplicación está terminada y puesta a funcionar en su ubicación definitiva.

El principal motivo para desaconsejar el ajuste debug=true en producción es que obtendremos menos rendimiento en la aplicación, ya que el código de depuración generado es menos eficiente.

Es muy habitual que los desarrolladores se olviden de desactivar la depuración en el web.config antes de subir la aplicación al servidor.

Detalles de los errores

Otro ajuste que es frecuente encontrarse mal establecido es el relativo a los mensajes detallados de error. Si colocamos el ajuste:

<customErrors mode="On">

en la configuración, siempre que se produzca un error no controlado se mostrarán los detalles a través de la típica “página amarilla de la muerte” (YSOD), que es como se conoce a las habituales páginas de error de ASP.NET.

JAMÁS debemos dejar que nuestras aplicaciones muestren los detalles de los errores a los usuarios. Aparte de denotar dejadez por parte de los programadores y falta de calidad de las aplicaciones,  a los usuarios tampoco les van a decir nada. Pero es que además mostrar esa información detallada de los errores revela multitud de información sobre cómo están hechas las aplicaciones e incluso, en casos extremos de chapuza, pueden revelar claves, estructuras de directorios, estructuras de bases de datos, etc… Esto proporciona información importante a posibles asaltantes de nuestro servidor, que pueden usarla para atacar nuestra aplicación.

Sin rodeos: mostrar detalles de los errores es una de las peores prácticas de seguridad universalmente reconocidas.

Una vez más, suele ser habitual que los desarrolladores suban aplicaciones a producción con este ajuste establecido.

¿Cómo podemos evitar estas malas prácticas?

Si somos responsables de algún servidor Web en producción sería muy conveniente que pudiésemos forzar de algún modo que los programadores cumplieran las buenas prácticas.

Esto es lo que podemos conseguir usando un ajuste poco conocido: <deployment retail>

Este ajuste sólo se puede indicar en la configuración global del servidor, es decir, en el archivo machine.config ubicado en C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config o similar (vale también para la versión 2.0 o superior de .NET).

Si abrimos este archivo y buscamos la sección “configuration•system.web” podemos establecer dicho atributo a true así:

<configuration>
    <system.web>
        <deployment retail=”true”/>
    </system.web>
</configuration>

Al hacerlo, da exactamente igual que el programador se haya olvidado de quitar el debug=true, las trazas o las páginas de error detalladas, ya que este ajuste prevalece sobre los locales de nuestra aplicación y deshabilita todas estas funciones.

Además, si vemos su definición en el mismo archivo machine.config, vemos que tiene establecido el atributo AllowDefinition=”MachineOnly”:

Esto significa que no podrá ser sobrescrito por configuraciones en niveles inferiores, es decir, que aunque algún programador intentase saltárselo poniendo lo mismo (pero a false) en el web.config, recibiría un error indicándole que no se puede sobrescribir e impediría que la aplicación funcionase.

Por todo ello, este poco conocido pero importante ajuste es algo que todos deberíamos asegurarnos de utilizar en los servidores que tengamos en producción.

¡Espero que te resulte útil!

La última versión de ASP.NET, la 4.0, incorpora varias opciones de configuración que tienen que ver con las URLs de nuestras páginas. Por ejemplo: los caracteres que son válidos y, por lo tanto, admitidos en una URL.

Por defecto existen 8 caracteres especiales que no se admiten en la ruta de una página, a saber:

<
>
&
*
%
:
\
?

La verdad es que es bastante lógico, puesto que no puede existir ningún archivo ni carpeta que los use en su nombre, y además el "et" o "ampersand" (&) y la interrogación (?) forman parte siempre de la parte de parámetros o "Query String" de una URL, no de la ruta.

Cuando se introduce uno de estos caracteres en una URL, ASP.NET devuelve un error 400, de petición errónea:

En ASP.NET 4.0 es posible definir la lista de caracteres no válidos en una URL tocando el web.config de la aplicación, en concreto el nodo httpRuntime en su propiedad requestPathInvalidChars:

<httpRuntime requestPathInvalidChars="&lt;,&gt;,*,%,&amp;,:,\,?"  />

Este es su valor por defecto que como vemos incluye los 8 caracteres que comentaba antes.

Si quisiésemos añadir algunos caracteres más que consideremos que no debemos admitir por seguridad, bastaría con incorporarlos a la lista anterior redefiniendo este nodo dentro de web.config.

Además, hay una serie de caracteres no imprimibles que si se intentaran utilizar producirían el mismo efecto, y no hay forma de quitarlos de la lista. Se trata de todos los caracteres ASCII que están entre el 0 y el 31 (el 32 es el primer caracter imprimible y es es el espacio en blanco). Estos caracteres son siempre no válidos por la misma definición de lo que es una URL, y es el propio sistema operativo a través del módulo http.sys quien se encarga de rechazar esas URLs (ni siquiera llega a .NET).

>> Longitud de las URL

Otro parámetro que ha sido constante hasta ahora en el mundo .NET es la longitud máxima de una ruta de nuestra aplicación: 260 caracteres. El motivo es que esta es la longitud máxima que se admite en el sistema de archivos NTFS, que al final es donde residen los archivos de nuestra aplicación.

Otro límite habitual ha sido el de la longitud máxima de la Query String (lo que va después de la ? en una URL, que define los parámetros de la petición). En ASP.NET el límite ha sido siempre de 2.048 caracteres. De hecho este límite debería ser más que suficiente, aunque la mayor parte de los navegadores lo superan: Internet Explorer soporta "sólo" 2.083 caracteres que ya es superior, pero otros navegadores como Opera (4.050 caracteres), Firefox (8.182 caracteres) o safari (8.184 caracteres) soportan como vemos muchos más.

A veces será útil modificar el límite autoimpuesto por ASP.NET de 2.048 caracteres. La mayor parte de las veces mi consejo sería reducir esta longitud ya que si tienes que enviar realmente tanta información mejor que uses un POST y no un GET, y si permites tamaños muy grandes se podrían utilizar para intentar saturar el servidor o hacer que falle tu aplicación si no se espera algo tan grande y trata de ahcer alguna conversión de datos, por ejemplo.

Tocando el mismo nodo de web.config que en el caso anterior puedes modificar ambos límites en ASP.NET 4.0:

<httpRuntime maxRequestPathLength="260" maxQueryStringLength="2048" />

El primer parámetro permite definir longitudes de ruta más largas o más cortas (se refiere a la parte de la URL que no es ni el  http://, ni el nombre del servidor, ni el QueryString). El segundo parámetro modifica la longitud permitida en el Query String.

>> Conclusión
Aunque generalmente no necesitarás tocar ninguno de estos parámetros es bueno saber que ahora puedes hacerlo si surge la necesidad. En cualquier caso es raro que una aplicación llegue a necesitar alcanzar esos límites de tamaño en las rutas, por lo que puede ser interesante cambiarlas por defecto para que sean más cortas y disminuir así la superficie de ataque por esta vía.

No te olvides tampoco de que estas limitaciones afectan tanto a peticiones "normales" desde el navegador, como a peticiones Ajax que no ves porque se hacen en segundo plano.

Por fin está disponible el anexo a mi libro de ASP.NET 4.0. Se trata de un pequeño capítulo adicional que explica unos pequeños cambios que ha habido en la versión definitiva respecto a la funcionalidad de plantillas HTML enlazadas a datos de ASP.NET Ajax Library, en el capítulo 5.

Básicamente explica cómo obtener la última versión del código de Script y sacarle partido desde ASP.NET o desde cualquier otra tecnología (PHP, JSP, MVC o incluso HTML puro y duro), y los pequeños cambios en sintaxis que ha habido en un par de características en la versión final.

Puedes leerlo íntegramente gratis on-line en Scribd:

Tecnologías ASP.NET 4.0 - Anexo A - Enlazado a datos AJAX

La caché de ASP.NET es una maravilla. Permite almacenar en memoria (o en otra ubicación, ya que es extensible) datos costosos de obtener y que no caduquen de inmediato. De esta forma las siguientes veces que debamos utilizarlos en la misma aplicación podremos obtenerlos desde la caché sin necesidad de volver a calcularlos o generarlos. Además la caché de ASP.NET ofrece un montón de características avanzadas que van más allá del simple almacenamiento. Por ejemplo podemos establecer caducidades de la información tanto en un determinado momento en el futuro, si no se utiliza tras un periodo, haciendo que unas informaciones dependan del valor de otras o creando dependencias de ciertos elementos externos (como un archivo, una consulta en la base de datos o una clave del registro).

Esto último es de especial interés, pues nos brinda la posibilidad de hacer cosas bastante complicadas sin apenas código. Por ejemplo, si nuestra aplicación depende de la información almacenada en un archivo en el disco duro, podemos leer sus contenidos, almacenarlos en caché e indicar que queremos que la caché caduque de inmediato en caso de que el archivo sea modificado externamente. Compáralo con el trabajo de conseguir lo mismo totalmente a mano.

Para abarcar toda la funcionalidad de la caché de .NET necesitaríamos un capítulo completo de un libro, y no es el objeto de este post. En MSDN tenemos acceso a toda la documentación al respecto.

El caso es que la versatilidad de la caché de ASP.NET ha hecho que muchos otros programadores quisieran usarla también en aplicaciones de escritorio y de otros ámbitos no atados a la Web. De hecho, en este mismo blog hablábamos hace más de 3 años de cómo conseguirlo. Lo que ocurre es que esto no dejaba de ser un apaño, y resultaba cuando menos extraño tener que añadir una referencia a System.Web.dll en nuestro proyecto. Incluso Microsoft/Avanade dentro de su Enterprise Library ha incluido siempre un módulo de caché para aplicaciones de escritorio con similares funcionalidades.

En .NET 4.0 la cosa se ha simplificado mucho. Se ha cambiado la implementación de la caché para que siga el modelo de proveedores (como en el resto de ASP.NET) para poder definir proveedores de caché propios y extender de diversas maneras la forma de almacenar la información. Y lo que más nos interesa para este post: se ha separado la implementación de la parte Web de la plataforma, para darle independencia y poder usarla en cualquier otro tipo de aplicación.

Ahora toda la funcionalidad de la caché se encuentra dentro del ensamblado System.Runtime.Caching y podemos hacer uso de uso clases desde cualquier tipo de aplicación, aunque hay algún truquillo que ahora mismo voy a contar.

Añadir una referencia a System.Runtime.Caching en una aplicación Windows Forms

Para probar cómo podemos usarla, vamos a crear un nuevo proyecto de Windows Forms en Visual Studio 2010. Lo primero que debemos tras haber creado el proyecto es añadir una referencia a System.Runtime.Caching, que nos habilitará el poder sacarle partido a la funcionalidad de caché.

Pulsamos con el botón derecho en el nodo del proyecto en el Explorador de Soluciones y elegimos la opción “Agregar Referencia”. Dentro de la pestaña .NET buscamos el ensamblado:

¡Eh! Un momento, ¿Qué pasa? No está en la GAC ¡Qué raro!

Es raro, pero no pasa nada. Vamos a buscarlo directamente en el disco duro, dentro de la carpeta de .NET en C:\Windows\Microsoft.NET\Framework\v4.0.30319. Ahí sí que está:

La añadimos, pero de repente observamos que en las referencias del proyecto aparece con una advertencia:

Si nos fijamos más, en la ventana de errores aparece un mensaje indicándonos que esa biblioteca no está preparada para trabajar con este perfil de .NET, y que la quitemos o que cambiemos el perfil.

¿Qué son los perfiles de .NET?

Un perfil de .Net es un subconjunto de la plataforma completa especialmente pensado para un tipo concreto de aplicación. En lugar de contener todas las funcionalidades de la plataforma ofrece sólo las interesantes para el perfil concreto con el que estemos trabajando. De esta forma si la aplicación típica de un determinado ámbito no necesita usar la funcionalidad completa de .NET puede usar sólo una parte y conseguiremos una descarga más pequeña del runtime de la plataforma. Un buen ejemplo son las aplicaciones Windows: ¿para qué vamos a distribuir con ellas todas las DLLs de la plataforma si en realidad no van a usar nada de la parte Web o la de Silverlight?. Esta funcionalidad está relacionada con la capacidad Multi-targeting de Visual Studio y ya apareció con la versión anterior en VS2008.

En Visual Studio 2010, por defecto, las aplicaciones de Windows Forms utilizan uno de estos perfiles, en concreto el denominado .NET Framework 4.0 Client Profile. Éste no incluye System.Runtime.Caching entre los ensamblados que puede utilizar, de ahí la advertencia, ya que luego en tiempo de ejecución en otra máquina puede que no estuviera disponible.

En este excelente post de Jossef Goldberg, del equipo de .Net en Microsoft, se explica la composición exacta de este perfil, qué funcionalidad contiene y cómo se compara con el mismo en .NET 3.5. También puedes ver qué ensamblados contiene el perfil viendo su definición en tu disco duro, en la ruta C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client. Finalmente puedes descargar el instalador de este perfil de la plataforma desde la Web de Microsoft.

Vale, ahora que ya sabemos qué es un perfil ¿cómo evitamos que se produzca la advertencia anterior?

Si vamos a las propiedades del proyecto Windows Forms, dentro de su pestaña “Application” tenemos un apartado para elegir contra qué versión de la plataforma queremos trabajar. Si desplegamos la lista podemos cambiar desde la versión cliente a la versión completa de la plataforma que es la inmediatamente anterior:

Al hacerlo y aceptar se nos avisa de que el proyecto tiene que cerrarse y volver a abrirse para poder realizar los cambios. Una vez hecho si vamos a agregar una referencia a la funcionalidad de Caching veremos que ahora sí está disponible desde la GAC, al ser la plataforma completa:

¡Listo!

Ahora ya podemos sacarle partido a la misma funcionalidad de caching que tendríamos en ASP.NET.

He dejado una pequeña descarga (ZIP, 14KB) con un ejemplo muy simple de uso para que se vea que realmente funciona sin problemas.

Sólo un detalle importante a tener en cuenta: la caché es privada para cada dominio de aplicación, por lo que sólo se puede acceder a la misma desde la propia aplicación que la ha creado. Esto es lógico por seguridad, pero alguien podría pensar que se podría compartir entre aplicaciones distintas o que si ejecutamos dos veces la misma aplicación tendríamos acceso a los mismos datos de caché. No es así y los datos almacenados sólo nos servirán dentro de ventanas o módulos que se ejecuten en la misma aplicación.

Imagino que se podría escribir una implementación propia de una caché que se saltase esos controles de algún modo, pero no es el verdadero objeto generalmente de este tipo de almacenamiento.

¡Espero que te sea útil!