Compartir a través de

Marco de seguridad: Administración de excepciones | Mitigaciones

Producto o servicio Artículo
WCF
API Web
Aplicación web

WCF: no incluir el nodo serviceDebug en el archivo de configuración

Título Detalles
Componente WCF
Fase de SDL Construir
Tecnologías aplicables Genérico, .NET Framework 3
Atributos N/A
References MSDN, Fortify Kingdom
Pasos Los servicios de Windows Communication Framework (WCF) se pueden configurar para exponer información de depuración. La información de depuración no debe usarse en entornos de producción. La <serviceDebug> etiqueta define si la característica de información de depuración está habilitada para un servicio WCF. Si el atributo includeExceptionDetailInFaults se establece en true, se devolverá información de excepción de la aplicación a los clientes. Los atacantes pueden aprovechar la información adicional que obtienen de la salida de depuración para montar ataques dirigidos al marco, la base de datos u otros recursos usados por la aplicación.

Ejemplo

El siguiente archivo de configuración incluye la <serviceDebug> etiqueta :

<configuration> 
<system.serviceModel> 
<behaviors> 
<serviceBehaviors> 
<behavior name=""MyServiceBehavior""> 
<serviceDebug includeExceptionDetailInFaults=""True"" httpHelpPageEnabled=""True""/> 
...

Deshabilite la información de depuración en el servicio. Esto se puede lograr quitando la <serviceDebug> etiqueta del archivo de configuración de la aplicación.

WCF: no incluir el nodo serviceMetadata en el archivo de configuración

Título Detalles
Componente WCF
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos Genérico, .NET Framework 3
References MSDN, Fortify Kingdom
Pasos Exponer públicamente información sobre un servicio puede proporcionar a los atacantes información valiosa sobre cómo podrían aprovechar el servicio. La <serviceMetadata> etiqueta habilita la característica de publicación de metadatos. Los metadatos del servicio pueden contener información confidencial que no debe ser accesible públicamente. Como mínimo, permita que los usuarios de confianza accedan a los metadatos y asegúrese de que no se expone información innecesaria. Mejor aún, deshabilite completamente la capacidad de publicar metadatos. Una configuración de WCF segura no contendrá la <serviceMetadata> etiqueta .

Asegúrese de que el control de excepciones adecuado se realiza en ASP.NET Web API

Título Detalles
Componente API Web
Fase de SDL Construir
Tecnologías aplicables MVC 5, MVC 6
Atributos N/A
References Exception Handling in ASP.NET Web API, Model Validation in ASP.NET Web API
Pasos De forma predeterminada, la mayoría de las excepciones no detectadas en ASP.NET Web API se traducen en una respuesta HTTP con código de estado 500, Internal Server Error

Ejemplo

Para controlar el código de estado devuelto por la API, HttpResponseException puede usarse como se muestra a continuación:

public Product GetProduct(int id)
{
    Product item = repository.Get(id);
    if (item == null)
    {
        throw new HttpResponseException(HttpStatusCode.NotFound);
    }
    return item;
}

Ejemplo

Para controlar aún más la respuesta de la excepción, la HttpResponseMessage clase se puede usar como se muestra a continuación:

public Product GetProduct(int id)
{
    Product item = repository.Get(id);
    if (item == null)
    {
        var resp = new HttpResponseMessage(HttpStatusCode.NotFound)
        {
            Content = new StringContent(string.Format("No product with ID = {0}", id)),
            ReasonPhrase = "Product ID Not Found"
        }
        throw new HttpResponseException(resp);
    }
    return item;
}

Para detectar excepciones no controladas que no son del tipo HttpResponseException, se pueden usar filtros de excepciones. Los filtros de excepciones implementan la System.Web.Http.Filters.IExceptionFilter interfaz . La manera más sencilla de escribir un filtro de excepción es derivar de la System.Web.Http.Filters.ExceptionFilterAttribute clase e invalidar el método OnException.

Ejemplo

Este es un filtro que convierte NotImplementedException excepciones en código 501, Not Implementedde estado HTTP :

namespace ProductStore.Filters
{
    using System;
    using System.Net;
    using System.Net.Http;
    using System.Web.Http.Filters;

    public class NotImplExceptionFilterAttribute : ExceptionFilterAttribute 
    {
        public override void OnException(HttpActionExecutedContext context)
        {
            if (context.Exception is NotImplementedException)
            {
                context.Response = new HttpResponseMessage(HttpStatusCode.NotImplemented);
            }
        }
    }
}

Hay varias maneras de registrar un filtro de excepción de API web:

  • Mediante acción
  • Por controlador
  • Globalmente

Ejemplo

Para aplicar el filtro a una acción específica, agregue el filtro como atributo a la acción:

public class ProductsController : ApiController
{
    [NotImplExceptionFilter]
    public Contact GetContact(int id)
    {
        throw new NotImplementedException("This method is not implemented");
    }
}

Ejemplo

Para aplicar el filtro a todas las acciones de un controller, agregue el filtro como atributo a la controller clase :

[NotImplExceptionFilter]
public class ProductsController : ApiController
{
    // ...
}

Ejemplo

Para aplicar el filtro globalmente a todos los controladores de API web, agregue una instancia del filtro a la GlobalConfiguration.Configuration.Filters colección. Los filtros de excepción de esta colección se aplican a cualquier acción del controlador de API web.

GlobalConfiguration.Configuration.Filters.Add(
    new ProductStore.NotImplExceptionFilterAttribute());

Ejemplo

Para la validación del modelo, el estado del modelo se puede pasar al método CreateErrorResponse como se muestra a continuación:

public HttpResponseMessage PostProduct(Product item)
{
    if (!ModelState.IsValid)
    {
        return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
    }
    // Implementation not shown...
}

Consulte los vínculos de la sección de referencias para obtener más detalles sobre el control excepcional y la validación de modelos en ASP.NET Web API

No exponer los detalles de seguridad en los mensajes de error

Título Detalles
Componente Aplicación web
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos N/A
References N/A
Pasos

Los mensajes de error genéricos se proporcionan directamente al usuario sin incluir datos confidenciales de la aplicación. Entre los ejemplos de datos confidenciales se incluyen:

  • Nombres de servidor
  • Cadenas de conexión
  • Nombres de usuario
  • Passwords
  • Procedimientos SQL
  • Detalles de errores dinámicos de SQL
  • Seguimiento de la pila y líneas de código
  • Variables almacenadas en memoria
  • Ubicaciones de discos y carpetas
  • Puntos de instalación de la aplicación
  • Opciones de configuración del host
  • Otros detalles internos de la aplicación

Capturar todos los errores dentro de una aplicación y proporcionar mensajes de error genéricos, así como habilitar errores personalizados en IIS ayudarán a evitar la divulgación de información. SQL Server y el manejo de excepciones de .NET, entre otras arquitecturas de gestión de errores, son especialmente verbosas y extremadamente útiles para un usuario malintencionado que perfila su aplicación. No muestre directamente el contenido de una clase derivada de la clase Exception de .NET y asegúrese de que tiene un control de excepciones adecuado para que una excepción inesperada no se genere accidentalmente directamente al usuario.

  • Proporcione mensajes de error genéricos directamente al usuario que abstrae los detalles específicos que se encuentran directamente en el mensaje de excepción o error.
  • No mostrar el contenido de una clase de excepción de .NET directamente al usuario
  • Interceptar todos los mensajes de error y, si procede, informar al usuario a través de un mensaje de error genérico enviado al cliente de la aplicación
  • No exponga el contenido de la clase Exception directamente al usuario, especialmente el valor devuelto de .ToString()o los valores de las propiedades Message o StackTrace. Registre esta información de forma segura y muestre un mensaje más inocuo al usuario.

Implementación de la página de gestión de errores predeterminada

Título Detalles
Componente Aplicación web
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos N/A
References Editar el cuadro de diálogo de configuración de páginas de error de ASP.NET
Pasos

Cuando se produce un error en una aplicación de ASP.NET y se produce un error de servidor interno HTTP/1.x 500, o una configuración de características (como filtrado de solicitudes) impide que se muestre una página, se generará un mensaje de error. Los administradores pueden elegir si la aplicación debe mostrar un mensaje descriptivo al cliente, un mensaje de error detallado al cliente o un mensaje de error detallado solo en localhost. La <customErrors> etiqueta del web.config tiene tres modos:

  • Activado: Especifica que los errores personalizados están habilitados. Si no se especifica ningún atributo defaultRedirect, los usuarios verán un error genérico. Los errores personalizados se muestran a los clientes remotos y al host local.
  • Desactivado: Especifica que los errores personalizados están deshabilitados. Los errores de ASP.NET detallados se muestran a los clientes remotos y al host local.
  • RemoteOnly: Especifica que los errores personalizados solo se muestran a los clientes remotos y que los errores ASP.NET se muestran en el host local. Este es el valor predeterminado

Abra el web.config archivo para la aplicación o el sitio, y asegúrese de que la etiqueta tiene definido el <customErrors mode="RemoteOnly" /> o el <customErrors mode="On" />.

Configurar el método de implementación a Comercial en IIS

Título Detalles
Componente Aplicación web
Fase de SDL Despliegue
Tecnologías aplicables Genérico
Atributos N/A
References elemento deployment (esquema de configuración de ASP.NET)
Pasos

El <deployment retail> conmutador está diseñado para su uso por los servidores IIS de producción. El conmutador se utiliza para ayudar a que las aplicaciones funcionen con el mejor rendimiento posible y la menor pérdida posible de información de seguridad al deshabilitar la capacidad de la aplicación para generar salida de seguimiento en una página, deshabilitar la capacidad de mostrar mensajes detallados de error a los usuarios finales y deshabilitar el conmutador de depuración.

A menudo, los conmutadores y opciones que están enfocadas hacia en el desarrollador, como los errores de solicitud de seguimiento y depuración, se habilitan durante el desarrollo activo. Se recomienda establecer el método de implementación en cualquier servidor de producción en modo retail. abra el archivo machine.config y asegúrese de que <deployment retail="true" /> permanece establecido en true.

Las excepciones deben fallar de manera segura

Título Detalles
Componente Aplicación web
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos N/A
References Fallar de forma segura
Pasos La aplicación debe generar un error con seguridad. Cualquier método que devuelva un valor booleano, en función del cual se tome cierta decisión, debe tener un bloque de excepciones cuidadosamente creado. Hay muchos errores lógicos que provocan problemas de seguridad cuando el bloque de excepciones se escribe sin cuidado.

Ejemplo

        public static bool ValidateDomain(string pathToValidate, Uri currentUrl)
        {
            try
            {
                if (!string.IsNullOrWhiteSpace(pathToValidate))
                {
                    var domain = RetrieveDomain(currentUrl);
                    var replyPath = new Uri(pathToValidate);
                    var replyDomain = RetrieveDomain(replyPath);

                    if (string.Compare(domain, replyDomain, StringComparison.OrdinalIgnoreCase) != 0)
                    {
                        //// Adding additional check to enable CMS urls if they are not hosted on same domain.
                        if (!string.IsNullOrWhiteSpace(Utilities.CmsBase))
                        {
                            var cmsDomain = RetrieveDomain(new Uri(Utilities.Base.Trim()));
                            if (string.Compare(cmDomain, replyDomain, StringComparison.OrdinalIgnoreCase) != 0)
                            {
                                return false;
                            }
                            else
                            {
                                return true;
                            }
                        }

                        return false;
                    }
                }

                return true;
            }
            catch (UriFormatException ex)
            {
                LogHelper.LogException("Utilities:ValidateDomain", ex);
                return true;
            }
        }

El método anterior siempre devolverá True, si se produce alguna excepción. Si el usuario final proporciona una dirección URL con formato incorrecto, que el explorador respeta, pero el Uri() constructor no, se producirá una excepción y la víctima se llevará a la dirección URL válida pero con formato incorrecto.

  • Last updated on