Compartilhar via

Quadro de Segurança: Gerenciamento de Exceções | Atenuações

Produto/Serviço Artigo
WCF
Web API
Aplicativo Web

WCF- Não incluir o elemento serviceDebug no arquivo de configuração

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

Exemplo

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

<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 <serviceDebug> marca do arquivo de configuração do aplicativo.

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

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

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

Title Detalhes
Componente Web API
Fase do SDL Construir
Tecnologias aplicáveis MVC 5, MVC 6
Atributos N/A
References Exception Handling in ASP.NET Web API, Model Validation in ASP.NET Web API
Etapas Por padrão, a maioria das exceções não capturadas em ASP.NET Web API são convertidas em uma resposta HTTP com código de status 500, Internal Server Error

Exemplo

Para controlar o código de status retornado pela API, HttpResponseException pode ser usado conforme mostrado abaixo:

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

Exemplo

Para obter mais controle 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 capturar exceções sem tratamento que não são do tipo HttpResponseException, filtros de exceção podem ser usados. Os filtros de exceção implementam a System.Web.Http.Filters.IExceptionFilter interface. A maneira mais simples de escrever um filtro de exceção é derivar da System.Web.Http.Filters.ExceptionFilterAttribute classe e substituir o método OnException.

Exemplo

Aqui está um filtro que converte exceções NotImplementedException em código 501, Not Implementedde status 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);
            }
        }
    }
}

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

  • Por ação
  • Por controlador
  • Globalmente

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 em 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 de API Web, adicione uma instância do filtro à GlobalConfiguration.Configuration.Filters coleção. Os filtros de exceção nesta coleção se aplicam a qualquer ação do controlador de API Web.

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

Exemplo

Para validação de 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...
}

Verifique os links na seção de referências para obter detalhes adicionais sobre manipulação excepcional e validação de modelo no ASP.NET Web API

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

Title Detalhes
Componente Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos N/A
References N/A
Etapas

Mensagens de erro genéricas são fornecidas diretamente ao usuário sem incluir dados confidenciais do aplicativo. Exemplos de dados confidenciais incluem:

  • Nomes de servidor
  • Cadeias de conexão
  • Nomes de usuário
  • Senhas
  • Procedimentos SQL
  • Detalhes de falhas dinâmicas do SQL
  • Rastreamento de pilha e linhas de código
  • Variáveis armazenadas na memória
  • Localizações de unidade e pasta
  • Pontos de instalação do aplicativo
  • Configurações do host
  • Outros detalhes internos do aplicativo

A captura de todos os erros em um aplicativo e o fornecimento de mensagens de erro genéricas, bem como a habilitação de erros personalizados no IIS, ajudarão a impedir a divulgação de informações. banco de dados SQL Server e tratamento de exceções do .NET, entre outras arquiteturas de tratamento de erros, são especialmente prolixos e extremamente úteis para um usuário mal-intencionado fazer o perfil do seu aplicativo. Não exiba diretamente o conteúdo de uma classe derivada da classe .NET Exception e verifique se você tem o tratamento de exceção adequado para que uma exceção inesperada não seja inadvertidamente gerada diretamente ao usuário.

  • Forneça mensagens de erro genéricas diretamente ao usuário que abstrai detalhes específicos encontrados diretamente na mensagem de exceção/erro
  • Não exiba o conteúdo de uma classe de exceção .NET diretamente para o usuário
  • Capturar todas as mensagens de erro e, se apropriado, informar o 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 ao usuário, especialmente o valor retornado de .ToString(), ou os valores das propriedades Message ou StackTrace. Registre essas informações com segurança e exiba uma mensagem mais inócua para o usuário

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

Title Detalhes
Componente Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos N/A
References Caixa de Diálogo de Editar Configurações de Páginas de Erro do ASP.NET
Etapas

Quando um aplicativo ASP.NET falha e causa um erro de servidor interno HTTP/1.x 500 ou uma configuração de recurso (como Filtragem de Solicitações) impede que uma página seja exibida, uma mensagem de erro será gerada. Os administradores podem escolher se o aplicativo deve ou não exibir uma mensagem amigável para o cliente, uma mensagem de erro detalhada para o cliente ou uma mensagem de erro detalhada somente para o localhost. A <customErrors> tag no web.config possui três modos:

  • Em: 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 de ASP.NET detalhados são mostrados aos clientes remotos e ao host local
  • RemoteOnly: Especifica que erros personalizados são mostrados apenas para os clientes remotos e que erros ASP.NET são mostrados para o host local. Este é o valor padrão

Abra o arquivo web.config do aplicativo/site e verifique se a tag tem <customErrors mode="RemoteOnly" /> ou <customErrors mode="On" /> definida.

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/A
References Elemento de Implantação (Esquema de Configurações ASP.NET)
Etapas

O <deployment retail> interruptor destina-se a ser usado por servidores IIS de produção. Essa opção é usada para ajudar os aplicativos a serem executados com o melhor desempenho possível e menos vazamentos de informações de segurança possíveis desabilitando a capacidade do aplicativo de gerar saída de rastreamento em uma página, desabilitando a capacidade de exibir mensagens de erro detalhadas para os usuários finais e desabilitando a opção de depuração.

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 ele <deployment retail="true" /> permanece definido como true.

As exceções devem falhar com segurança

Title Detalhes
Componente Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos N/A
References Falha com segurança
Etapas O aplicativo deve falhar com segurança. Qualquer método que retorna um valor booliano, com base no qual determinada decisão é tomada, deve ter o bloco de exceção cuidadosamente criado. Há muitos erros lógicos devido a quais problemas de segurança ocorrem, quando o bloco de exceção é escrito descuidadamente.

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

  • Last updated on