Moldura de Segurança: | de Gestão de Exceções Mitigações
| Produto/Serviço | Artigo |
|---|---|
| WCF | |
| API Web | |
| Aplicação Web |
WCF – Não inclua o nó serviceDebug no ficheiro de configuração
| Título | Detalhes |
|---|---|
| Componente | WCF |
| Fase SDL | Compilação |
| Tecnologias Aplicáveis | Genérico, NET Framework 3 |
| Atributos | N/D |
| Referências | MSDN, Fortify Kingdom |
| Passos | Os serviços do Windows Communication Framework (WCF) podem ser configurados para expor informações de depuração. As informações de depuração não devem ser utilizadas 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 verdadeiro, as informações de exceção da aplicação serão devolvidas aos clientes. Os atacantes podem tirar partido das informações adicionais obtidas com a depuração da saída para montar ataques direcionados para a arquitetura, base de dados ou outros recursos utilizados pela aplicação. |
Exemplo
O seguinte ficheiro de configuração inclui a <serviceDebug> etiqueta:
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name=""MyServiceBehavior"">
<serviceDebug includeExceptionDetailInFaults=""True"" httpHelpPageEnabled=""True""/>
...
Desative as informações de depuração no serviço. Isto pode ser feito ao remover a <serviceDebug> etiqueta 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 | Compilação |
| Tecnologias Aplicáveis | Genérica |
| 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 ativa a funcionalidade 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 os utilizadores fidedignos acedam aos metadados e certifique-se de que as informações desnecessárias não são expostas. Melhor ainda, desative totalmente a capacidade de publicar metadados. Uma configuração WCF segura não conterá a <serviceMetadata> etiqueta. |
Certifique-se de que o processamento de exceções adequado é feito na API Web ASP.NET
| Título | Detalhes |
|---|---|
| Componente | API Web |
| Fase SDL | Compilação |
| Tecnologias Aplicáveis | MVC 5, MVC 6 |
| Atributos | N/D |
| Referências | Processamento de Exceções na API Web ASP.NET, Validação de Modelos na API Web ASP.NET |
| Passos | Por predefinição, a maioria das exceções não escritas no ASP.NET API Web são traduzidas numa resposta HTTP com código de estado 500, Internal Server Error |
Exemplo
Para controlar o código de estado devolvido pela API, pode ser utilizado conforme HttpResponseException 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 controlo sobre a resposta de exceção, a HttpResponseMessage classe pode ser utilizada 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 não processadas que não sejam do tipo HttpResponseException, podem ser utilizados Filtros de Exceção. Os 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 substituir o método OnException.
Exemplo
Eis um filtro que converte exceções NotImplementedException 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çã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 num 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 aplicam-se a qualquer ação do controlador de API Web.
GlobalConfiguration.Configuration.Filters.Add(
new ProductStore.NotImplExceptionFilterAttribute());
Exemplo
Para validação de modelos, o estado do modelo pode ser transmitido 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 as ligações na secção de referências para obter detalhes adicionais sobre o processamento excecional e a validação de modelos no ASP.NET API Web
Não expor detalhes de segurança em mensagens de erro
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Compilação |
| Tecnologias Aplicáveis | Genérica |
| Atributos | N/D |
| Referências | N/D |
| Passos | As mensagens de erro genéricas são fornecidas diretamente ao utilizador sem incluir dados confidenciais da aplicação. Exemplos de dados confidenciais incluem:
Intercetar todos os erros numa aplicação e fornecer mensagens de erro genéricas, bem como ativar erros personalizados no IIS, ajudará a impedir a divulgação de informações. SQL Server base de dados e o processamento de exceções .NET, entre outras arquiteturas de processamento de erros, são especialmente verbosos e extremamente úteis para um utilizador mal intencionado que cria perfis para a sua aplicação. Não apresente diretamente o conteúdo de uma classe derivada da classe Exceção .NET e certifique-se de que tem o processamento de exceções adequado para que uma exceção inesperada não seja inadvertidamente gerada diretamente para o utilizador.
|
Página Implementar Processamento de erros predefinido
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Compilação |
| Tecnologias Aplicáveis | Genérica |
| Atributos | N/D |
| Referências | Caixa de Diálogo Editar Definições de Páginas de Erro .NET |
| Passos | Quando uma aplicação de ASP.NET falha e causa um Erro de Servidor Interno HTTP/1.x 500 ou uma configuração de funcionalidade (como Filtragem de Pedidos) impede a apresentação de uma página, será gerada uma mensagem de erro. Os administradores podem escolher se a aplicação deve ou não apresentar uma mensagem amigável ao cliente, uma mensagem de erro detalhada ao cliente ou uma mensagem de erro detalhada apenas para localhost. A
Abra o |
Definir o Método de Implementação como Revenda no IIS
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Implementação |
| Tecnologias Aplicáveis | Genérica |
| Atributos | N/D |
| Referências | Deployment Element (ASP.NET Settings Schema) (Elemento deployment (Esquema de Definições de ASP.NET) |
| Passos | O Muitas vezes, os comutadores e opções focados no programador, como o rastreio de pedidos falhados e a 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 revenda. abra o ficheiro machine.config e certifique-se de que |
As exceções devem falhar com segurança
| Título | Detalhes |
|---|---|
| Componente | Aplicação Web |
| Fase SDL | Compilação |
| Tecnologias Aplicáveis | Genérica |
| Atributos | N/D |
| Referências | Falhar 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 aos quais os problemas de segurança ocorrem, quando o bloco de exceção é escrito descuidado. |
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, se ocorrer alguma exceção. Se o utilizador final fornecer um URL com formato incorreto, que o browser respeita, mas o Uri() construtor não, esta ação irá gerar uma exceção e a vítima será levada para o URL válido, mas mal formado.