Dicas para configurar uma aplicação ASP.NET segura

O Framework .NET vem com uma série de recursos para você configurar uma aplicação ASP.NET de forma segura, evitando e/ou dificultando que alguém mal intencionado burle seu sistema. Algumas dessas configurações são ativadas por padrão, porém algumas vezes elas são alteradas em ambiente de desenvolvimento e acabam sendo utilizadas também no ambiente de produção.

Vamos dar uma olhada em algumas dicas de configuração que podem melhorar a segurança de sua aplicação ASP.NET. Algumas dessas configurações são bem simples e muitas vezes passam despercebidas pelos desenvolvedores.

Todas as configurações a seguir devem ser feitas no arquivo Web.config de sua aplicação ASP.NET.

Validate Request

Essa configuração ajuda a reduzir ataques de Cross-site scripting (XSS), validando a entrada de dados.

<configuration>
  ...
  <system.web>
    <pages validateRequest="true">
      ...
    </pages>
  <system.web>
</configuration>

A valor padrão de validate request é true e também pode ser configurada no escopo de página:

<%@ Page ValidateRequest="false" ... %>

Custom Errors

Quantas vezes você não se deparou com um erro em uma aplicação ASP.NET, que exibia uma página semelhante a essa:

Essa página de erro padrão do ASP.NET (também conhecida como Yellow Screen of Death) exibe uma série de informações que podem ser úteis para usuários mal intencionados atacarem seu site, como por exemplo o caminho físico da sua aplicação e o nome das suas classes.

Sempre utilize páginas de erros customizadas em ambiente de produção:

<configuration>
  ...
  <system.web>
    <customErrors mode="RemoteOnly" />
    ...
  <system.web>
</configuration>

Configure o atributo mode para RemoteOnly (valor padrão), para somente exibir a página de erro padrão rodando a aplicação localmente, ou para On para sempre exibir páginas de erros customizadas em qualquer ambiente.

Trace

Informações de trace são úteis para quando você está desenvolvendo a aplicação e podem ser mais úteis ainda para quem pretende atacar seu site. Portanto, nunca habilite o trace em produção.

<configuration>
  ...
  <system.web>
    <trace enabled="false" pageOutput="false" localOnly="true" />
    ...
  <system.web>
</configuration>

Todos os valores dos atributos da configuração de trace acima são padrão.

Debug

Assim como o trace, o modo debug deve ser usado somente em ambiente de desenvolvimento.

<configuration>
  ...
  <system.web>
    <compilation debug="false">
      ...
    </compilation>
  <system.web>
</configuration>

A configuração padrão para debug é false, mas praticamente todo programador .NET habilita o modo de debug para desenvolver. Então fique atento para desabilitá-lo em ambiente de produção.

Connection Strings

O cenário ideal para se conectar em um banco de dados através de uma aplicação .NET é usar Windows Authentication. Dessa forma, no arquivo de configuração não haverá nenhum dado de usuário e senha do banco de dados. Por exemplo, conectando ao SQL Server:

<configuration>
  ...
  <connectionStrings>
    <add name="MyConnectionString"
         connectionString="Data Source=MyServerAddress;Initial Catalog=MyDataBase;Integrated Security=SSPI;"
         providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

Mas se sua aplicação usa a forma de autenticação com usuário e senha, como por exemplo SQL Server Authentication, nunca armazene as strings de conexão sem criptografia no arquivo de configuração.

Uma maneira de criptograr esses dados no Web.config é utilizar a ferramenta Aspnet_regiis.exe com o comando -pe (provider encryption) via command prompt, como mostra o exemplo abaixo:

aspnet_regiis -pe "connectionStrings" -app "/MyApp" -prov "DataProtectionConfigurationProvider"

Lembrando que o uso dessa ferramenta deve ser feita no servidor onde está o IIS com sua aplicação configurada.

Para mais informações sobre como criptografar seções do Web.config e o uso do Aspnet_regiis.exe, acesse os links abaixo:
How To Encrypt Connection Strings in ASP.NET
ASP.NET IIS Registration Tool (Aspnet_regiis.exe)

Cookies

HttpOnly

Configurar o acesso aos cookies somente via HTTP, evita que o código do lado do cliente, por exemplo JavaScript, interaja com os cookies, técnica muito usada para ações de XSS.

<configuration>
  ...
  <system.web>
    <httpCookies httpOnlyCookies="true" />
    ...
  <system.web>
</configuration>

A configuração acima vai adicionar a parâmetro HttpOnly na cabeçalho HTTP Set-Cookie, conforme exemplo abaixo:

Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly

Atenção, o valor padrão para httpOnlyCookies é false.

Para mais informações sobre HttpOnly, acesse http://www.owasp.org/index.php/HttpOnly.

Require SSL

Se você utiliza HTTPS na sua aplicação, poderá habilitar a transmissão de cookies via SSL.

<configuration>
  ...
  <system.web>
    <httpCookies requireSSL="true" />
    ...
  <system.web>
</configuration>

Dessa forma, nenhum cookie será gravado em páginas que utilizar HTTP. Por padrão, o uso de SSL em cookies vem desabilitado.

Forms Authentication

Cookie Name

Sempre informe um nome para o cookie de autenticação, ao invés de usar o nome padrão ".ASPXAUTH".

<configuration>
  ...
  <system.web>
    <authentication mode="Forms">
      <forms name="MyCookieName" ... />
    </authentication>
    ...
  <system.web>
</configuration>

Cookie Path

Da mesma forma que o nome, o ideal é sempre informar um caminho válido para o cookie de autenticação, no lugar do valor padrão "/".

<configuration>
  ...
  <system.web>
    <authentication mode="Forms">
      <forms path="/my_path" ... />
    </authentication>
    ...
  <system.web>
</configuration>

Cookie Less

Por padrão, o valor do parâmetro cookieless é UseDeviceProfile. Isso faz com que o token de autenticação somente seja armazenado em cookie para dispositivos que tenham suportes a cookies. Caso a aplicação seja acessada por um dispositivo que não suporte cookie, o token de autenticação aparecerá na URL, abrindo uma brecha para ataques.

Configurando cookieless para UseCookies, forçará a utilização de cookies para o token de autenticação, independente se o dispositivo que acessa a aplicação tenha suporte a cookies ou não.

<configuration>
  ...
  <system.web>
    <authentication mode="Forms">
      <forms cookieless="UseCookies" ... />
    </authentication>
    ...
  <system.web>
</configuration>

Require SSL

É uma boa prática usar HTTPS para reforçar a segurança do processo de autenticação da sua aplicação. Essa configuração irá forçar o uso de SSL para autenticar os usuários.

<configuration>
  ...
  <system.web>
    <authentication mode="Forms">
      <forms requireSSL="true" ... />
    </authentication>
    ...
  <system.web>
</configuration>

O valor padrão para requireSSL é false.

Sliding Expiration

Configurar sliding expiration para true (seu valor padrão) fará com que o tempo de expiração da autenticação se renove a cada nova requisição em uma sessão autenticada. Se o token de autenticação é roubado, o atacante poderá se manter autenticado indefinidamente, bastando realizar uma nova requisição antes do tempo de expiração.

Para dificultar esses ataques, configure sliding expiration para false. Dessa forma, o tempo de expiração da autenticação será fixo, independente de novas requisições, invalidando o token de autenticação após esse período.

<configuration>
  ...
  <system.web>
    <authentication mode="Forms">
      <forms slidingExpiration="false" ... />
    </authentication>
    ...
  <system.web>
</configuration>

Redirecionamento para outras aplicações

Por padrão o redirecionamento para outras aplicações é desabilitado. Alterar essa configuração pode abrir uma brecha de segurança na sua aplicação para compartilhar informações com outros sites.

<configuration>
  ...
  <system.web>
    <authentication mode="Forms">
      <forms enableCrossAppRedirects="false" ... />
    </authentication>
    ...
  <system.web>
</configuration>

Credentials

A primeira recomendação é: NÃO USE. Armazenar dados de usuários e senhas no arquivo de configuração, mesmo que sejam criptografados, não tem nada de seguro. Existem outras formas mais seguras para armazenar essas informações, como um banco de dados, por exemplo.

Muitas vezes esse recurso é utilizado para facilitar os testes em ambiente de desenvolvimento. Nunca coloque essa configuração em produção. E mesmo em ambiente de desenvolvimento, não altere o valor padrão "SHA1"do formato de criptografia da senha.

<configuration>
  ...
  <system.web>
    <authentication mode="Forms">
      <forms ... >
        <credentials passwordFormat="SHA1">
          <user name="my_user_name" password="31BF3856AD364E35" />
        </credentials>
      </forms>
    </authentication>
    ...
  <system.web>
</configuration>

Exemplo de configuração forms authentication

<configuration>
  ...
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="adm/login.aspx"
             name="InfoqCookie"
             path="/infoqapp"
             cookieless="UseCookies"
             requireSSL="true"
             slidingExpiration="false"
             enableCrossAppRedirects="false"
             protection="All"
             timeout="10" />
    </authentication>
    ...
  <system.web>
</configuration>

View State

Não coloque dados sigilosos no view state, pois esse valores ficam expostos na página através de um input hidden de forma não criptografada.

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTE2MTY2ODcyMjkPFgIeCHBhc3N3b3JkBQlzd29yZGZpc2hkZA==" />

Nos valores do view state somente são aplicados uma codificação de base 64, ou seja, pode ser facilmente decodificada. Inclusive, existem ferramentas que fazem esse decodificação facilmente, como oViewSate Decoder.

Uma alternativa para aumentar a segurança do que é armazenado no view state é habilitar o modo de criptografia, que por padrão é desabilitado.

<configuration>
  ...
  <system.web>
    <pages viewStateEncryptionMode="Always">
      ...
    </pages>
  <system.web>
</configuration>

Para informações mais detalhadas sobre segurança do view state, veja esse artigo da MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/ff797918.aspx.

Web.config Security Analyzer

Para ajudar os desenvolvedores que desejam configurar uma aplicação ASP.NET segura, a H-Security Labs criou o WCSA, Web.config Security Analyzer, uma ferramenta que analisa o arquivo de configuração com a finalidade de encontrar vulnerabilidades de segurança.

O WCSA faz mais de 30 verificações de segurança e gera um relatório detalhado com a descrição das vulnerabilidades encontradas, sugestão de configuração e referências a respeito do problema.

Use esse link para baixá-lo: http://code.google.com/p/wcsa