1. Custom Errors en Off
Cuando desactivas los custom errors como se ve abajo, ASP.NET mostrará en pantalla los errores detallados a aquellos usuarios que vean la página que muestra dicho error.Configuración Vulnerable:
<configuration>
<system.web>
<customErrors mode="Off">
Así se ve, todo el detalle:
Configuración Segura:
<configuration>
<system.web>
<customErrors mode="RemoteOnly">
Así se vería ahora, mucho más seguro a cara del usuario:
Si no lo dejas así se verá la versión específica del Framework, el tipo de excepción por ejemplo si dice SqlException no sería muy lindo ya que se vería la versión del SQL, versión de IIS u otros detalles.
Algunos usan mode="On" y usan una página específica de errores con el atributo "defaultRedirect", ambas son válidas opciones, como se ve abajo:
<customErrors mode="On" defaultRedirect="ErrorGenerico.aspx"/>
<customErrors mode="RemoteOnly" defaultRedirect="ErrorGenerico.aspx"/>
2. Dejar activo el Tracing para aplicaciones Web
La característica de trace es muy útil para depurar un error, pero si es vista por un usuario que quiere atacar a tu sitio Web sería desastroso.Configuración Vulnerable
<configuration>
<system.web>
<trace enabled="true" localOnly="false">
Configuración Segura:
<configuration>
<system.web>
<trace enabled="false" localOnly="true">
Cuando está activo <trace> pero para usuarios remotos (localOnly="false") cualquier usuario puede ver el detalle de los request recientes simplemente ejecutando la página "trace.axd": http://mistio.com/trace.axd
Si está así es una verdadera mina de oro para un atacante. Se verán cookies, tiempos de ejecución, estado de la sesión, headers de los request, variables QuerySrings, etc.
Si quieres depurar un error, lo habilitas, pero sólo para verlo desde el mismo servidor (entrando al servidor):
<trace enabled="true" localOnly="true">
3. Dejar activado Debug
Se debe trabajar en etapa de desarrollo como deploy en True, pero luego desactivar. Ojo que Visual Studio 2005 lo activa por defecto cuando le das F5 y luego en el Deploy, es muy común copiar ese mismo Web.Config a producción olvidando quitar el "debug=true".Configuración Vulnerable:
<configuration>
<system.web>
<compilation debug="true">
Configuración Segura:
<configuration>
<system.web>
<compilation debug="false">
Al activar muestra información muy peligrosa a un Usuario atacante como por ejemplo la línea con error, el stack trace y una parte del código fuente incluso.
4. Cookies accesibles por el lado del cliente
En Internet Explorer 6.0, Microsoft introdujo una nueva propiedad llamada "HttpOnly". Esta opción permite crear un cookie pero ella sólo será posible leerla o verla desde el servidor y no por el cliente con JavaScript por ejemplo. Se puede setear cookie a cookie por código pero lo mejor es setear todo el sitio con Cookie seguras:Configuración Vulnerable:
<configuration>
<system.web>
<httpCookies httpOnlyCookies="false">
Configuración Segura:
<configuration>
<system.web>
<httpCookies httpOnlyCookies="true">
Con esto las cookies creadas en el servidor se pueden leer desde allí y no con scripts del cliente con JavaScript o VBScript. Si por código está activada "httpOnlyCookies = false", pero el Web.Config está en True, este último manda y tendrás el sitio seguro.
5. Dejar el Session State por URI y no por Cookies
En la versión 1.0 de ASP.NET, no había forma de decidir como transmitir el token de session entre request cuando la aplicación necesita mantener el estado de la sesión, este siempre se almacenaba en una cookie. Los usuarios que no aceptaban el uso de cookie no podía usar la aplicación, así que en ASP.NET 1.1, Microsoft agregó soporte para un token de sesión en base a la URI. Esto a la vez, es más inseguro ya que se ve en pantalla el token:Configuración Vulnerable:
<configuration>
<system.web>
<sessionState cookieless="UseUri">
Configuración Segura:
<configuration>
<system.web>
<sessionState cookieless="UseCookies">
El estado de la session se puede manejar por URL y no por Cookie, por ejemplo si la URL cambia de http://myserver/MyApplication/default.aspx a http://myserver/MyApplication/(123456789ABCDEFG)/default.aspx. En este caso "123456789ABCDEFG" representa el token actual de sesión. Una diferente navegación al sitio genera una totalmente diferente token de sesión mostrando la url por ejemplo as http://myserver/MyApplication/(ZYXWVU987654321)/default.aspx.
Esto es práctico pero inseguro ya que con Fiddler o un sniffer se puede rastrear esa parte de la URL y un atacante habilidoso podría hacer mal uso del token.
La más eficiente forma para proteger de un sniffer es usar "UseCookies" o sencillamente setear "false". Pero no por URI. Ahora si usas "UseCookies" es obvio que dependes que el usuario tenga permitido el uso de cookies en su navegador.
¿Qué hacer con los que no permiten el uso de cookies en su navegador? En ese caso, desde el ASP.NET 2.0. se puede poner el atributo "cookieless" en "AutoDetect", por lo que la aplicación guardará el estado de la session en la Cookie solo si está activado en el navegador. Si no lo está, lo dejará en la URI. Ahora, entre los ataques más fáciles de realizar para un atacante, el de la URL es más vulnerable, por lo tanto, recomiendo usar "UseCookies".
Post original: https://dotnetstories.wordpress.com/2007/10/13/the-worst-5-mistakes-in-the-webconfig-file/
