ASP.NET W3Clogger.loggingFields pode ser configurado para permitir o registro de dados confidenciais, como dados privados e do sistema Informação.
Esses dados podem conter informações confidenciais relacionadas a solicitações HTTP e respostas HTTP, como clientes/IP do servidor, portas do servidor, cookies de cabeçalho e nomes de usuários autenticados que acessaram o servidor.

Em caso de violação de dados, o adversário pode usar essas informações para:

- Roubar informações confidenciais ou representar um usuário com privilégios mais altos.
- Descobrir servidores internos e obter acesso não autorizado a recursos restritos.
- Elaborar ataques concentrados em explorar vulnerabilidades conhecidas relatadas contra o servidor detectado


Exemplo 1: O seguinte código mostra um método de ação em um controlador em que a validação foi desativada:

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;

    ... )

Example 1 mostra como o W3Clogging pode ser configurado, usando o sinalizador All, para registrar todos os campos possíveis na Solicitação Http, incluindo dados confidenciais, como ClientIpAddress, ServerName, ServerIpAddress, ServerPort, UserName e Cookie.

O método FormsAuthentication.RedirectFromLoginPage() emite um tíquete de autenticação, que permite que os usuários permaneçam autenticados por um período de tempo especificado. Quando o método é invocado com o segundo argumento false, ele emite um tíquete de autenticação temporário que permanece válido por um período de tempo configurado em web.config. Quando invocado com o segundo argumento true, o método emite um tíquete de autenticação persistente. No .NET 2.0, o tempo de vida do tíquete persistente respeita o valor em web.config, mas, no .NET 1.1, esse tíquete de autenticação persistente tem um tempo de vida padrão ridiculamente longo -- cinquenta anos.

Permitir que tíquetes de autenticação persistentes sobrevivam por um longo período de tempo deixa os usuários e o sistema vulneráveis das seguintes maneiras:

Expande o período de exposição a ataques de sequestro de sessão para usuários que não conseguem fazer logout.

Aumenta o número médio de identificadores de sessão válidos disponíveis para um invasor adivinhar.

Prolonga a duração da exploração quando um invasor consegue sequestrar a sessão de um usuário.

Definir useUnsafeHeaderParsing como true relaxa o processamento de cabeçalhos HTTP. Regras de validação excessivamente permissivas em cabeçalhos HTTP podem permitir uma variedade de ataques contra aplicativos vulneráveis.



Especificamente, quando esta propriedade é definida como falsa, as seguintes regras de validação não são mais aplicadas:

No código de fim de linha, use CRLF; usar CR ou LF sozinho não é permitido.

Os nomes dos cabeçalhos não devem conter espaços.

Se houver várias linhas de status, todas as linhas de status adicionais serão tratadas como pares malformados de nome/valor de cabeçalho.

A linha de status deve ter uma descrição de status, além de um código de status.

Os nomes dos cabeçalhos não podem conter caracteres não ASCII. Esta validação é executada se esta propriedade for definida como verdadeira ou falsa.

Quando ocorre uma violação de protocolo, uma exceção WebException é lançada com o status definido como ServerProtocolViolation. Se a propriedade UseUnsafeHeaderParsing for definida como true, os erros de validação serão ignorados.

Definir essa propriedade como true tem implicações de segurança, portanto, só deve ser feito se a compatibilidade com versões anteriores com um servidor for necessária.


Exemplo 1: No exemplo a seguir, useUnsafeHeaderParsing está definido como "true".

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest  useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...

No ASP.NET, o estado de exibição é um mecanismo para persistir o estado em formulários da web em postbacks. Os dados armazenados no estado de exibição não são confiáveis porque não há mecanismo para evitar ataques de repetição. Confiar no estado de exibição é particularmente perigoso quando a verificação de autenticação da mensagem do estado de exibição está desabilitada. Desabilitar essa verificação permite que os invasores façam alterações arbitrárias nos dados armazenados no estado de exibição e pode abrir a porta para ataques contra códigos que confiam no estado de exibição. Os invasores podem usar esse tipo de erro para anular as verificações de autenticação ou alterar o preço do item.

O MVC ASP.NET fornece uma maneira conveniente de proteger melhor um aplicativo contra falsificação de solicitações entre sites, adicionando um token antifalsificação no lado do formulário e validando esse token no controlador. Se usado, esse token é geralmente incluído como um campo de formulário oculto, sendo validado quando o formulário é enviado, o que aumenta as chances de uma solicitação ser proveniente do seu aplicativo e não falsificada.

O código de controlador a seguir não inclui defesa interna contra falsificação de solicitações entre sites:

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}

O MVC ASP.NET fornece uma maneira conveniente de proteger melhor um aplicativo contra falsificação de solicitações entre sites, adicionando um token antifalsificação ao formulário HTML e validando esse token no controlador. Se usado, esse token é geralmente incluído como um campo de formulário oculto, sendo validado quando o formulário é enviado, o que aumenta as chances de uma solicitação ser proveniente do seu aplicativo e não falsificada.

Em geral, um programador deve incluir esse token antifalsificação, pois ele aumenta o custo de criação de scripts mal-intencionados contra um aplicativo.

Exemplo 1:o seguinte código Razor cria um formulário no HTML resultante sem a defesa integrada contra falsificação de solicitação entre sites:

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
  // ... form elements
}

Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:

@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
  // ... form elements
}

O método do representante NSURLConnectionDelegate.connection(_:willSendRequestFor:) permite que o representante tome imediatamente uma decisão bem-informada sobre a autenticação de conexão. Se o representante implementar esse método, não será necessário implementar NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) ou NSURLConnectionDelegate.connection(_:didReceive:). Na verdade, esses métodos não são chamados e, portanto, qualquer verificação de segurança neles será ignorada.