Partilhar via

Quadro de Segurança: Gestão de Exceções | Mitigações

Produto/Serviço Artigo
WCF
API Web
Aplicação Web

WCF - Não incluir o nó serviceDebug no ficheiro de configuração

Título Detalhes
Componente WCF
Fase SDL Construir
Tecnologias aplicáveis Genérico, NET Framework 3
Atributos N/A
Referências MSDN e Fortify Kingdom
Passos Os serviços do Windows Communication Framework (WCF) podem ser configurados para expor informações de depuração. A informação de depuração não deve ser usada em ambientes de produção. A <serviceDebug> etiqueta define se a funcionalidade de informação de depuração está ativada para um serviço WCF. Se o atributo includeExceptionDetailInFaults estiver definido como true, a informação de exceção da aplicação será devolvida aos clientes. Os atacantes podem aproveitar a informação adicional obtida com a depuração para realizar ataques direcionados ao framework, base de dados ou outros recursos utilizados pela aplicação.

Exemplo

O ficheiro de configuração seguinte inclui a <serviceDebug> etiqueta:

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

Desativar a depuração de informações no serviço. Isto pode ser conseguido removendo a <serviceDebug> tag do ficheiro de configuração da sua aplicação.

WCF - Não inclua o nó serviceMetadata no ficheiro de configuração

Título Detalhes
Componente WCF
Fase SDL Construir
Tecnologias aplicáveis Genérico
Atributos Genérico, NET Framework 3
Referências MSDN, Fortify Kingdom
Passos Expor publicamente informações sobre um serviço pode fornecer aos atacantes informações valiosas sobre como podem explorar o serviço. A <serviceMetadata> etiqueta permite a funcionalidade de publicação de metadados. Os metadados do serviço podem conter informações sensíveis que não deveriam ser acessíveis publicamente. No mínimo, permitir apenas que utilizadores de confiança acedam aos metadados e garantir que informações desnecessárias não sejam expostas. Melhor ainda, desative completamente a capacidade de publicar metadados. Uma configuração WCF segura não conterá a <serviceMetadata> etiqueta.

Garantir que o tratamento adequado das exceções é feito na ASP.NET Web API

Título Detalhes
Componente API Web
Fase SDL Construir
Tecnologias aplicáveis MVC 5, MVC 6
Atributos N/A
Referências Tratamento de exceções em ASP.NET Web API, Validação de Modelos em ASP.NET Web API
Passos Por padrão, a maioria das exceções não capturadas em ASP.NET Web API são convertidas numa resposta HTTP com código de estado 500, Internal Server Error

Exemplo

Para controlar o código de estado devolvido pela API, HttpResponseException pode ser usado como mostrado abaixo:

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

Exemplo

Para um controlo adicional sobre a resposta de exceção, a HttpResponseMessage classe pode ser usada conforme mostrado abaixo:

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 detetar exceções não tratadas que não são do tipo HttpResponseException, podem ser usados Filtros de Exceção. Filtros de exceção implementam a System.Web.Http.Filters.IExceptionFilter interface. A forma mais simples de escrever um filtro de exceção é derivar da System.Web.Http.Filters.ExceptionFilterAttribute classe e sobrescrever o método OnException.

Exemplo

Aqui está um filtro que converte NotImplementedException exceções em 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);
            }
        }
    }
}

Existem várias formas de registar um filtro de exceções da Web API:

  • Por meio de uma ação
  • Por controlador
  • A nível global

Exemplo

Para aplicar o filtro a uma ação específica, adicione o filtro como um atributo à ação:

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

Exemplo

Para aplicar o filtro a todas as ações sobre um controller, adicione o filtro como um atributo à controller classe:

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

Exemplo

Para aplicar o filtro globalmente a todos os controladores Web API, adicione uma instância do filtro à GlobalConfiguration.Configuration.Filters coleção. Filtros de exceção nesta coleção aplicam-se a qualquer ação do controlador da Web API.

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

Exemplo

Para validação do modelo, o estado do modelo pode ser passado para o método CreateErrorResponse, conforme mostrado abaixo:

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

Consulte os links na secção de referências para mais detalhes sobre manuseamento excecional e validação de modelos na ASP.NET Web API

Não exponha detalhes de segurança em mensagens de erro

Título Detalhes
Componente Aplicação Web
Fase SDL Construir
Tecnologias aplicáveis Genérico
Atributos N/A
Referências N/A
Passos

Mensagens de erro genéricas são fornecidas diretamente ao utilizador sem incluir dados sensíveis da aplicação. Exemplos de dados sensíveis incluem:

  • Nomes dos servidores
  • Cadeias de ligação
  • Nomes de utilizador
  • Passwords
  • Procedimentos SQL
  • Detalhes das falhas dinâmicas em SQL
  • Rastreio de pilha e linhas de código
  • Variáveis armazenadas na memória
  • Localização de discos e pastas
  • Pontos de instalação de aplicações
  • Definições de configuração do host
  • Outros detalhes internos da aplicação

Capturar todos os erros dentro de uma aplicação e fornecer mensagens de erro genéricas, bem como ativar erros personalizados no IIS, ajudará a prevenir a divulgação de informação. O tratamento de exceções nas bases de dados SQL Server e em .NET, entre outras arquiteturas de tratamento de erros, são especialmente verbosas e extremamente úteis para um utilizador malicioso que analise a sua aplicação. Não mostre diretamente o conteúdo de uma classe derivada da classe de exceção .NET e certifique-se de que tem um tratamento adequado das exceções para que uma exceção inesperada não seja inadvertidamente elevada diretamente ao utilizador.

  • Forneça mensagens de erro genéricas diretamente ao utilizador que abstraiam detalhes específicos encontrados diretamente na mensagem de exceção/erro
  • Não mostre o conteúdo de uma classe de exceção .NET diretamente ao utilizador
  • Captura todas as mensagens de erro e, se apropriado, informe o utilizador através de uma mensagem de erro genérica enviada ao cliente da aplicação
  • Não exponha o conteúdo da classe Exception diretamente ao utilizador, especialmente o valor de retorno de .ToString(), ou os valores das propriedades Message ou StackTrace. Registe esta informação de forma segura e mostre uma mensagem mais inofensiva ao utilizador

Implementar a página de tratamento de erros padrão

Título Detalhes
Componente Aplicação Web
Fase SDL Construir
Tecnologias aplicáveis Genérico
Atributos N/A
Referências Editar Caixa de Diálogo de Configurações de Páginas de Erro do ASP.NET
Passos

Quando uma aplicação ASP.NET falha e causa um Erro de Servidor Interno HTTP/1.x 500, ou uma configuração de funcionalidades (como Filter de Pedidos) impede que uma página seja exibida, será gerada uma mensagem de erro. Os administradores podem escolher se a aplicação deve mostrar uma mensagem amiga ao cliente, uma mensagem de erro detalhada ao cliente ou uma mensagem de erro detalhada apenas ao localhost. A <customErrors> etiqueta no web.config tem três modos:

  • Sobre: Especifica que os erros personalizados estão ativados. Se não for especificado o atributo defaultRedirecte, os utilizadores veem um erro genérico. Os erros personalizados são mostrados aos clientes remotos e ao host local
  • Desligado: Especifica que erros personalizados estão desativados. Os erros detalhados do ASP.NET são mostrados aos clientes remotos e ao host local
  • RemoteOnly: Especifica que os erros personalizados são mostrados apenas aos clientes remotos e que ASP.NET erros são mostrados ao host local. Este é o valor padrão

Abra o ficheiro web.config da aplicação/site e certifique-se de que a etiqueta tem <customErrors mode="RemoteOnly" /> ou <customErrors mode="On" /> definido.

Defina o método de distribuição para Retalho no IIS

Título Detalhes
Componente Aplicação Web
Fase SDL Implementação
Tecnologias aplicáveis Genérico
Atributos N/A
Referências Elemento implementação (Esquema de Definições ASP.NET)
Passos

O <deployment retail> switch destina-se a ser utilizado por servidores IIS de produção. Este interruptor é usado para ajudar aplicações a funcionar com o melhor desempenho possível e com o menor número possível de fugas de informação de segurança, desativando a capacidade da aplicação de gerar saída de traço numa página, desativando a possibilidade de mostrar mensagens de erro detalhadas aos utilizadores finais e desativando o interruptor de depuração.

Muitas vezes, switches e opções focados no programador, como rastreamento de pedidos falhados e depuração, são ativados durante o desenvolvimento ativo. Recomenda-se que o método de implementação em qualquer servidor de produção seja definido como retalho. Abra o ficheiro machine.config e certifique-se de que permanece <deployment retail="true" /> definido como verdadeiro.

As exceções devem falhar de forma segura

Título Detalhes
Componente Aplicação Web
Fase SDL Construir
Tecnologias aplicáveis Genérico
Atributos N/A
Referências Falhe de forma segura
Passos A aplicação deve falhar em segurança. Qualquer método que devolva um valor booleano, com base no qual determinada decisão é tomada, deve ter um bloco de exceção cuidadosamente criado. Existem muitos erros lógicos devido a problemas de segurança que surgem quando o bloco de exceção é escrito de forma descuidada.

Exemplo

        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;
            }
        }

O método acima devolverá sempre Verdadeiro, caso ocorra alguma exceção. Se o utilizador final fornecer um URL mal formado, que o navegador respeita, mas o Uri() construtor não, isto lançará uma exceção, e a vítima será levada para o URL válido mas malformado.

  • Last updated on