Quadro de segurança: Gerenciamento de exceções| Mitigações

Produto/Serviço	Artigo
WCF	WCF - não inclui o nó serviceDebug no arquivo de configuração WCF - não inclui o nó serviceMetadata no arquivo de configuração
API da Web	Verificar se o tratamento de exceções adequado é feito na ASP.NET Web API
Aplicativo Web	Não expor os detalhes da segurança nas mensagens de erro Implementar a página de tratamento de erros Padrão Definir o Método de Implantação para o Varejo no IIS As exceções devem falhar com segurança

WCF - não inclui o nó serviceDebug no arquivo de configuração

Title	Detalhes
Componente	WCF
Fase do SDL	Build
Tecnologias aplicáveis	Genérico, NET Framework 3
Atributos	N/D
Referências	MSDN, Fortify Kingdom
Etapas	Os serviços do Windows Communication Framework (WCF) podem ser configurados para expor as informações de depuração. As informações de depuração não devem ser usadas nos ambientes de produção. A marcação <serviceDebug> define se o recurso das informações de depuração está habilitado para um serviço WCF. Se o atributo includeExceptionDetailInFaults for definido para true, as informações de exceção do aplicativo serão retornadas aos clientes. Os invasores podem aproveitar as informações adicionais que eles obtêm na saída da depuração para montar ataques direcionados na estrutura, banco de dados ou outros recursos usados pelo aplicativo.

Exemplo

O arquivo de configuração a seguir inclui a marcação <serviceDebug>:

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

Desabilite as informações de depuração no serviço. Isso pode ser feito removendo a marcação <serviceDebug> do arquivo de configuração de seu aplicativo.

WCF - não inclui o nó serviceMetadata no arquivo de configuração

Title	Detalhes
Componente	WCF
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	Genérico, NET Framework 3
Referências	MSDN, Fortify Kingdom
Etapas	Expor publicamente as informações sobre um serviço pode dar aos invasores ideias valiosas sobre como eles podem explorar o serviço. A marcação <serviceMetadata> habilita o recurso de publicação de metadados. Os metadados do serviço podem conter informações confidenciais e não devem ser acessíveis publicamente. No mínimo, apenas permita que usuários confiáveis acessem os metadados e verifique se informações desnecessárias não são expostas. Melhor ainda, desabilite totalmente a capacidade de publicar metadados. Uma configuração segura do WCF não conterá a marcação <serviceMetadata>.

Verificar se o tratamento de exceções adequado é feito na ASP.NET Web API

Title	Detalhes
Componente	API Web
Fase do SDL	Build
Tecnologias aplicáveis	MVC 5, MVC 6
Atributos	N/D
Referências	Tratamento de Exceções na ASP.NET Web API, Validação do Modelo na ASP.NET Web API
Etapas	Por padrão, a maioria das exceções não identificadas na ASP.NET Web API é convertida em uma resposta HTTP com um código de status500, Internal Server Error

Exemplo

Para controlar o código de status retornado 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 ter mais controle sobre a resposta da exceção, a classe HttpResponseMessage pode ser usada como 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 capturar as exceções sem tratamento que não são do tipo HttpResponseException, podem ser usados Filtros de Exceção. Os Filtros de Exceção implementam a interface System.Web.Http.Filters.IExceptionFilter. A maneira mais simples de escrever um filtro de exceção é derivar da classe System.Web.Http.Filters.ExceptionFilterAttribute e substituir o método OnException.

Exemplo

Aqui está um filtro que converte as exceções NotImplementedException no código de status HTTP 501, Not Implemented:

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

Há várias maneiras de registrar um filtro de exceção da API Web:

• por ação
• pelo controlador
• globalmente

Exemplo

Para aplicar o filtro em 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 em todas as ações em um controller, adicione o filtro como um atributo à classe controller:

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

Exemplo

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

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

Exemplo

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

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

Verificar os links na seção de referências para obter detalhes adicionais sobre o tratamento de exceção e a validação do modelo na ASP.NET Web API

Não expor os detalhes da segurança nas mensagens de erro

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	N/D
Etapas	As mensagens de erro genéricas são fornecidas diretamente para o usuário sem incluir os dados confidenciais do aplicativo. Exemplos de dados confidenciais: nomes do servidor Cadeias de conexão nomes de usuário Senhas procedimentos SQL detalhes das falhas SQL dinâmicas rastreamento de pilha e linhas de código variáveis armazenadas na memória locais da pasta e da unidade pontos de instalação do aplicativo definições de configuração do host outros detalhes internos do aplicativo Interceptar todos os erros em um aplicativo e fornecer mensagens de erro genéricas, bem como habilitar os erros personalizados no IIS, ajudará a evitar a divulgação das informações. O banco de dados do SQL Server e o tratamento Exception do .NET, entre outras arquiteturas de tratamento de erros, são especialmente detalhados e extremamente úteis para um usuário mal-intencionado que cria o perfil de seu aplicativo. Não exiba diretamente o conteúdo de uma classe derivada da classe Exception do .NET e verifique se você tem o tratamento adequado das exceções para que uma exceção inesperada não seja gerada sem querer diretamente para o usuário. Fornecer mensagens de erro genéricas diretamente para o usuário que abstrai os detalhes específicos encontrados diretamente na mensagem de erro/exceção Não exibir o conteúdo de uma classe exception do .NET diretamente para o usuário Interceptar todas as mensagens de erro e se apropriado, informar ao usuário por meio de uma mensagem de erro genérica enviada ao cliente do aplicativo Não exponha o conteúdo da classe Exception diretamente para o usuário, especialmente o valor de retorno de .ToString() ou os valores das propriedades Message ou StackTrace. Registrar essas informações com segurança e exibir uma mensagem mais inofensiva para o usuário

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

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Caixa de Diálogo Editar Configurações das Páginas de Erro do ASP.NET
Etapas	Quando um aplicativo ASP.NET falhar e fizer com que um Erro Interno do Servidor HTTP/1.x 500 ou uma configuração do recurso (por exemplo, Filtragem da Solicitação) impeça que uma página seja exibida, uma mensagem de erro será gerada. Os administradores podem escolher se o aplicativo deve exibir ou não uma mensagem amigável para o cliente, mensagem de erro detalhada para o cliente ou mensagem de erro detalhada para o localhost apenas. A marcação <customErrors> no web.config tem três modos: Ativado: Especifica que os erros personalizados estão habilitados. Se nenhum atributo defaultRedirect for especificado, os usuários verão um erro genérico. Os erros personalizados são mostrados para os clientes remotos e para o host local Desativado: Especifica que os erros personalizados estão desabilitados. Os erros detalhados do ASP.NET são mostrados para os clientes remotos e o host local RemoteOnly: Especifica que os erros personalizados são mostrados apenas para os clientes remotos e que os erros do ASP.NET são mostrados para o host local. Esse é o valor padrão. Abra o arquivo web.config do aplicativo/site e verifique se a marcação foi <customErrors mode="RemoteOnly" /> ou <customErrors mode="On" /> definido.

Definir o Método de Implantação para o Varejo no IIS

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Implantação
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	implantação Element (Esquema de Configurações do ASP.NET)
Etapas	O argumento <deployment retail> é para ser usado pelos servidores IIS de produção. Esse argumento é usado para ajudar os aplicativos a serem executados com o melhor desempenho possível e o mínimo de vazamento de informações de segurança desabilitando a capacidade dele de gerar a saída de rastreamento em uma página, desabilitando a capacidade de exibir mensagens de erro detalhadas para os usuários finais e desativando o argumento debug. Muitas vezes, os argumentos e as opções que estão voltados para os desenvolvedores, como um rastreamento da solicitação e depuração com falha, são habilitados durante o desenvolvimento ativo. É recomendável que o método de implantação, em qualquer servidor de produção, seja definido para varejo. abra o arquivo machine.config e verifique se <deployment retail="true" /> permanece definido para true.

As exceções devem falhar com segurança

Title	Detalhes
Componente	Aplicativo Web
Fase do SDL	Build
Tecnologias aplicáveis	Genérico
Atributos	N/D
Referências	Falhar com segurança
Etapas	O aplicativo deve falhar com segurança. Qualquer método que retorna um valor booliano, com base em qual determinada decisão é tomada, deve ter um bloco de exceção criado cuidadosamente. Há muitos erros lógicos devido a problemas de segurança que passam quando o bloco de exceção é escrito com negligência.

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 sempre retornará True se ocorrer uma exceção. Se o usuário final fornecer uma URL malformada, que o navegador respeita, mas o construtor Uri() não, isso irá gerar uma exceção e a vítima será levada para uma URL válida, mas malformada.