Performance, Segurança e Boas Práticas


Recentemente um amigo me procurou para dar algumas dicas se segurança e performance para melhorar de uma aplicação Web. Depois da ajuda, eu decidi disponibilizar essa listagem aqui no blog. Compilei algumas dicas e disponibilizei abaixo essa listagem, com algumas guidelines que julgo necessárias para quando for desenvolver e disponibilizar a aplicação em um servidor Web. É importante dizer que isso pode ou não ser importante, dependendo de qual o cenário da aplicação/empresa.

  • Performance
    • Desabilite a Session nas páginas que você não precisa dela. Isso pode ser realizado através do atributo EnableSessionState da diretiva @Page. Se não for utilizar na aplicação como um tudo, então desabilite a nível de aplicação, através do elemento enableSessionState no elemento do arquivo Web.Config.
    • Sempre defina para false a propriedade EnableViewState para quando não precisar do ViewState na página Web. Através do atributo maxPageStateFieldlength definido dentro do elemento , você tem a possibilidade de “quebrar” o campo __VIEWSTATE. Mas isso não traz melhora em termos de performance. Essa configuração é útil para quando alguns proxies e firewalls barram o acesso a determinadas páginas, quando ela, por sua vez, contém campos ocultos com um grande conteúdo.
    • Defina o atributo debug do elemento compilation para false. Quando definido como true em ambiente de produção, é um dos grandes vilões de performance. Se desejar que todas as aplicações do servidor Web obrigatoriamente estejam com este mesmo comportamento, voce pode definir para true o valor do atributo retail do elemento deployment do arquivo Machine.config do servidor Web.
    • Considere a utilização de OutputCache. Para facilitar a manutenção, utilize o CacheProfile.
    • Remova todos os módulos que não estão sendo utilizados pela aplicação.
    • Reduza a quantidade de round-trips entre o cliente e o servidor. Para isso, utilize sempre que possível o método Server.Transfer.
    • A compactação da resposta a ser enviada para o cliente é sempre uma boa opção. Além disso, remova caracteres desnecessários, como espaços em branco e TABs.
    • Utilize sempre DataReader para ter uma forma eficiente de carga de dados.
    • Paginar os resultados é quase sempre uma necessidade para exibição de dados.
    • Defina para true o atributo enableKernelOutputCache do elemento httpRuntime (acredito que isso já seja o padrão). Isso tem um benefício a nível do IIS, mas atente-se que, em alguns cenários, essa configuração pode trazer resultados inesperados.
    • Remova todos os HTTP Headers desnecessários. Quando você instala o .NET Framework, é criado um valor por padrão dentro do IIS, que é enviado como resposta para todos os clientes que consomem a aplicação. Geralmente é algo como: “X-Powered by ASP.NET”. Você pode remover diretamente do IIS ou via atributo enableVersionHeader do elemento httpRuntime.
    • Considere a utilização de páginas assíncronas quando possível.
  • Segurança
    • Toda aplicação Web roda sempre em FullTrust. Considere utilizar Medium (partial trust) já que ela atende a maioria dos casos, inclusive na versão 2.0 do .NET Framework, esse nível já concede acesso ao SqlClientPermission, responsável por gerenciar o acesso à servidores SQL Server. Para alterar esse nível, você pode utilizar o atributo level do elemento trust no arquivo Web.Config da aplicação ou do servidor Web, se desejar que todas as aplicações que estão rodando ali sejam definidas como medium trust.
    • Não permita que outros desenvolvedores sobrescrevam a sua policy. Para isso, defina o atributo allowOverride como false.
    • Sempre crie uma página padrão de erros para que os usuários seja redirecionados para ela quando um problema ocorrer. Para isso, configure a seção do arquivo Web.Config. Neste mesmo local, evite que as exceções sejam enviadas para os usuários, definindo o atributo mode para RemoteOnly. Isso evitará exibir detalhes da exceção que ocorreu, qual pode comprometer a sua aplicação.
    • Todos os parâmetros fornecidos pelo usuário (Forms, QueryStrings, etc.) devem ser validados por tamanho, tipo e formato.
    • Páginas importantes, que podem sofrer alguma espécie de ataque, podemos configurar a sua propriedade ViewStateUserKey para um valor qualquer (Session.SessionID), evitando assim, ataques de “one-click”.
    • Nunca armazene informações sigilosas em QueryStrings ou ViewState. Se necessitar armazenar algo importante no ViewState, então criptografe-o. Para isso defina o valor “Auto” para o atributo viewStateEncryptionMode do elemento e invoque o método RegisterRequiresViewStateEncryption na página em que deseja armazenar o conteúdo sigiloso no ViewState.
    • Use SSL somente em páginas que realmente precisam deste nível de segurança.
    • Criptografe a seção de connectionStrings.
    • Criptografe a seção de appSettings quando ele possui informações confidenciais.
    • Quando for conectar com uma base de dados qualquer, utilize um usuário que só tenha permissão necessária para manipular os objetos que estão sendo utilizados pela aplicação, nada mais.
    • Sempre armazena password “hasheados” na sua base de dados. Quando utiliza a arquitetura do Membership, ele já fornece isso intrinsicamente.
    • Defina para true o atributo httpOnlyCookies do elemento httpCookies no arquivo Web.Config. Esse atributo permite ou não que código client-side acessem o cookie.
  • Boas Práticas
    • Sempre extraia strings de arquivos de Resources (*.resx). Mais cedo ou mais tarde, alguém sempre pede para você globalizar a aplicação. 🙂
    • Defina o nome da aplicação no atributo applicationName quando utilizar o Membership/RoleProvider/Profile.
    • Se estiver utilizando o tratamento global de exceções, habilite o Health Monitoring para logar as exceções e efetuar uma posterior análise.
    • Desabilite o Trace em produção. Quando precisar habilitá-lo para poder monitorar alguma requisição, então define o atributo localOnly como true, para que o output possa ser somente visualizado no próprio computador onde a aplicação está sendo executada.

Bem, de momento o que me veio a cabeça é isso. É muito provável que existe outros detalhes que devo ter esquecido ao colocar aqui.

Publicidade

2 comentários sobre “Performance, Segurança e Boas Práticas

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s