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!

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA