10 consejos para escribir aplicaciones seguras en ASP.NET

La seguridad es uno de los aspectos más importantes de cualquier aplicación, y cuando hablamos de seguridad, especialmente en ASP.NET aplicaciones, no se limita al desarrollo.

Una aplicación segura implica varias capas de seguridad en la configuración, el marco, el servidor web, el servidor de base de datos y más. En esta publicación, echaremos un vistazo a los nueve mejores consejos para escribir aplicaciones seguras en ASP.NET.

1. Cross Site Scripting (XSS)

Esta vulnerabilidad permite a un atacante inyectar código malicioso al introducir datos. Puede ser código JavaScript, script VB o cualquier otro código de script. De forma predeterminada, ASP.NET MVC valida las entradas y arroja un error del servidor en caso de script. Digamos que ponemos el script en el formulario de entrada:

Cuando enviamos la página anterior, obtendremos el siguiente error:

De forma predeterminada, el motor de vista de Razor protege de los ataques XSS. Pero hay ciertos escenarios (blogs, aplicaciones sociales, etc.) en los que es posible que necesitemos permitir etiquetas html en los controles de entrada. Para eso, tenemos una opción para agregar el filtro ValidateInput como falso:

[HttpPost]
[ValidateInput(false)]
public async Task < ActionResult > Register(RegisterViewModel model) {
    if (ModelState.IsValid) {
        //  Etc.
    }
}

Pero esto es muy arriesgado porque aquí no validamos la solicitud completa. Digamos que el modelo tiene veinte propiedades, todas estarán exentas de la validación, mientras que es posible que necesitemos permitir html en solo uno o unos pocos controles.

En ese escenario, en lugar de usar este ValidateInput, deberíamos poner el atributo AllowHTML en la propiedad específica de ViewModel como:

public class RegisterViewModel {
    [Required]
    [AllowHtml]
    [Display(Name = "User Name")]
    public string Name {
        get;
        set;
    }
...
}

Ahora podemos usar etiquetas solo para el nombre.

2. Falsificación de recursos entre sitios (CSRF)

CSRF (también conocido como ataque de un clic) es un tipo de ataque malicioso en el que se disparan comandos no autorizados desde un sitio web de confianza donde el usuario está autenticado. En un escenario del mundo real, supongamos que el usuario inició sesión en una aplicación con autenticación basada en Windows/cookies. Ahora, sin cerrar la sesión, el usuario visita un sitio malicioso y hace clic en un botón. El sitio web externo inicia una solicitud a través de su sitio web para realizar una operación poco ética. Se considerará como una solicitud válida porque la solicitud está autenticada.

Para evitar ataques CSRF, MVC proporciona el mecanismo AntiForgeryToken. Para eso, necesitamos usar el ayudante AntiForgeryToken en vista como

@Html.AntiForgeryToken()

Y para validar el token, necesitamos poner el filtro Antiforgerytoken sobre la acción como:

[ValidateAntiForgeryToken]
public async Task < ActionResult > Register(RegisterViewModel model) {
    if (ModelState.IsValid) {
        // etc.
    }
    return View(model);
}

Crea dos tokens en respuesta, uno se establece como una cookie y el otro se establece en un campo oculto como:

<form action="/Account/Register" class="form-horizontal" method="post" role="form">
<input name="__RequestVerificationToken" type="hidden" value="Qorw9RPABdHoRC7AojnSnQYYuGZP5iPF63UFVSw_[…]" />

Al enviar el formulario, ambos tokens (cookie y campo oculto) se envían al servidor. Ambos se validan en el servidor, y si alguno de ellos no está presente o está manipulado, entonces la solicitud no está permitida.

3. Handling Errors Properly

Es probable que ocurran errores y encuentran la manera de llegar al usuario. Pero si no se manejan adecuadamente, los errores pueden filtrar información interna al mundo exterior, lo que puede ser una amenaza para la aplicación. Seguir YSOD es común cuando se produce una excepción no controlada:

Pero vea la cantidad de información que muestra al mundo exterior: código interno, estructura de archivos físicos, seguimiento de pila y la versión de ASP.NET y .NET Framework.

Una solución rápida podría ser configurar el modo customErrors de la siguiente manera:

<customErrors mode="On"></customErrors> 

Esto mostrará una página de error predeterminada ASP.NET en caso de cada error. Para manejarlo de una mejor manera, use el modo de errores personalizado RemoteOnly y tenga una página de error común que se muestre en caso de error.

<customErrors mode="RemoteOnly" redirectMode="ResponseRewrite" defaultRedirect="~/Error.aspx" />

Aquí mostramos nuestra propia página de error en caso de error.

Inyección de 4. SQL

La inyección SQL es una vulnerabilidad de seguridad bien conocida, pero aún no se maneja correctamente en muchas aplicaciones. La inyección SQL permite a los piratas informáticos manipular los datos existentes, modificar transacciones o incluso eliminar datos o bases de datos, lo que puede ser una gran pérdida para el negocio.

Con esta técnica, el hacker inyecta algunos comandos SQL maliciosos a través de la entrada. Estos comandos tienen el poder de cambiar la instrucción SQL que se ejecuta en el servidor.  Digamos que al autenticar a un usuario en una aplicación, hemos escrito una consulta en una clase como:

"select * from Users where UserName='"+txtUserName.Text+"'and Password='"+txtPwd.Text+"' ";

Ahora el usuario pone el siguiente valor en el nombre de usuario:

Ahora la consulta se generará en el servidor como:

select * from Users where UserName='’ or 1=1 --' and Password='"+txtPwd.Text+"' ";

Esto siempre devolverá elementos y permitirá a los usuarios ingresar a la aplicación.

Para manejar esto, la mejor manera es usar el procedimiento almacenado SQL donde pasaremos los valores un parámetro o al menos usaremos los parámetros como:

"select * from Users where UserName= @username and Password=@password”

5. Click-Jacking

El click-jacking es otra vulnerabilidad importante que se ignora normalmente. En este caso, el atacante utiliza una capa opaca para engañar al usuario para que haga clic en un botón o enlace en una página diferente (por ejemplo, un botón de transferencia en el sitio web del banco) mientras está destinado a hacer clic en la página de nivel superior.

Para evitar este problema, no debemos permitir que se abra ningún sitio web de diferente dominio en iframe. Para lograr esto, necesitamos agregar un encabezado de respuesta X-FRAME-OPTIONS como deny o sameorigin. En ASP.NET, podemos establecer en Global.asax como:

void Application_BeginRequest(object sender, EventArgs e)
{
    HttpContext.Current.Response.AddHeader("X-FRAME-OPTIONS ", "DENY");
}

Agregará el encabezado en todas las respuestas enviadas por la aplicación.

También podemos usar IIS para agregar el mismo encabezado. En IIS, vaya al sitio web deseado y vaya a la pestaña Encabezados HTTP y agregue un encabezado personalizado con el encabezado X-FRAME-OPTIONS como se ha explicado. Deberá reiniciar IIS para que entre en vigor.

6. Ocultar la estructura de la aplicación / listado de directorios

¿Le gustaría compartir la estructura de carpetas de su aplicación con el usuario final?  ¡No! ¿Derecha? Veamos un ejemplo. He implementado ASP.NET aplicación predeterminada de formularios web en IIS, por lo que ahora, cuando accedo a la dirección URL, muestra:

Muestra todos los archivos y carpetas disponibles en Cuenta. Esta información puede ser una amenaza potencial para la aplicación si está disponible públicamente.

La exploración de directorios debe estar deshabilitada en IIS. Cuando está desactivado, vemos:

Devuelve 403 (prohibido), pero eso aún deja alguna vulnerabilidad ya que le dice al usuario que esta carpeta está disponible. Cuando intentamos acceder a un directorio que no está disponible, devuelve 404.

Para esto, podemos escribir nuestro propio controlador http personalizado y configurarlo para que siempre devuelva 404 cada vez que alguien intente acceder a una carpeta.

7. Encrypt Sensitive Information in Web.config

Muchas veces colocamos información crítica en el Web.config, más comúnmente la cadena de conexión.

Para cifrar cualquier parte de la cadena de conexión, debemos navegar a la carpeta del marco en el símbolo del sistema (por ejemplo, C:\Windows\Microsoft.NET\Framework\v4.0.30319 ) y ejecutar el siguiente comando:

aspnet_regiis -pef "connectionStrings" path

Aquí path es la ruta de la carpeta donde reside Web.config. Después de ejecutar el comando, se muestra como:

Del mismo modo, podemos cifrar otras secciones como <appsettings> etc.

8. Secure Cookies

Las cookies son pequeños textos almacenados por los navegadores en las máquinas de los usuarios que viajan entre el servidor web y el navegador. Las cookies se utilizan para almacenar información relacionada con el usuario para el sitio web específico. En ASP.NET, el ID de sesión es una de las piezas de información más comunes para las que se utilizan cookies para guardar.

Como esta información se almacena en texto sin formato en la máquina de un usuario, podría ser un objetivo fácil para los atacantes. Hay un par de pasos que debemos seguir para evitar almacenar datos en las cookies, como establecer una fecha de caducidad y cifrar los datos. Aparte de estos dos pasos, hay dos cosas más que debemos hacer:

1. Permitir cookies solo en SSL
2. Configure las cookies como HTTPOnly. Esto asegura que las cookies no puedan ser leídas por el script del lado del cliente, por lo que nuestra sesión o token de autenticación de formulario no pudo leerse en un navegador.

Podemos hacer los ajustes en Web.config como:

<httpCookies domain="String" httpOnlyCookies="true "requireSSL="true " />

9. Encrypting View State

View State es una de las técnicas más comunes que se usan para mantener el estado entre las devoluciones de página en ASP.NET formularios web. El estado de vista se guarda en una variable oculta en la página con id__VIEWSTATE. Cuando vemos eso en la fuente de la vista, encontramos que contiene una serie de números y caracteres. Asegúrese de que no esté encriptado sino en formato base64. Cualquiera puede decodificarlo para leer la información.

Hay dos opciones para cifrar y hacerlo a prueba de manipulaciones. Existe la propiedad ViewStateEncryptionMode, que se puede establecer en el nivel de página en el archivo aspx o se puede establecer en Web.config, que se aplica a todas las páginas de la aplicación. Cifra el estado de la vista antes de ponerlo en la respuesta. Del mismo modo, otra propiedad, EnableViewStateMac, se puede establecer como verdadera en la página o en Web.config. Crea un hash del contenido del estado de vista y lo agrega en el campo oculto. En la siguiente publicación, nuevamente se crea y verifica el hash. Si no coincide, se rechaza la devolución y se produce un error.

10. Elimine la información confidencial de los encabezados de respuesta

Este es el encabezado de respuesta de una página de una aplicación ASP.NET:

Aquí podemos ver que está revelando demasiada información al usuario final, que no necesitan como en la versión de IIS, el sitio construido y la versión ASP.NET. Si un atacante conoce las lagunas de alguno de ellos, puede explotar la vulnerabilidad. Esta información se agrega de forma predeterminada y debemos eliminarla a menos que sea específicamente necesario.

1. Para eliminar ASP.NET encabezado de versión, solo necesitamos agregar lo siguiente en Web.config:

<system.web>
  <httpRuntime enableVersionHeader="false" />
</system.web>

2. Para eliminar la versión de MVC, debemos ir AppliCation_Start evento en Global.asax y agregar el siguiente código:

MvcHandler.DisableMvcResponseHeader = true;

3. X-Power-By es agregado por IIS y se puede quitar agregando la siguiente configuración

  <system.webServer>
        <httpProtocol>
            <customHeaders>
                <remove name="X-Powered-By" />
            </customHeaders>
        </httpProtocol>
  </system.webServer>

Conclusión

En esta publicación, discutimos que la seguridad es clave para cualquier aplicación web y, si no se maneja adecuadamente, puede dañar significativamente el negocio. Discutimos nueve de las vulnerabilidades más comunes de ASP.NET aplicaciones web y vimos que la mayoría de ellas se pueden solucionar haciendo algún cambio de configuración o cambios menores en el código.

¡Cree aplicaciones empresariales con todas las funciones para cualquier navegador con Infragistics ASP.NET controles! Descargue la versión de prueba gratuita ahora.