A segurança de aplicação é um tópico quente. Ninguém quer escrever código que leve à próxima violação de dados ou manchete principal. C# segurança está na mente de muitos desenvolvedores .NET.

A codificação segura envolve conhecimento detalhado de uma linguagem de programação e estrutura. Pode haver dezenas de regras articuladas aqui com exemplos de código detalhados mostrando práticas de codificação certas versus erradas. No entanto, isso pode levar a um pouco de leitura seca e baixa retenção. Em vez disso, vou pegar um ângulo diferente. Descreverei três princípios que levam a práticas de codificação fortes e seguras. Aprenda bem esses princípios e você poderá garantir qualquer aplicação que construir.

C# Princípio de Segurança #1: Entenda os Detalhes (e Perigos) do Seu Quadro Escolhido

C# segurança não é apenas sobre a linguagem em si. Lembre-se que há uma estrutura e biblioteca de classe por trás disso. Problemas de segurança podem surgir quando os desenvolvedores usam recursos da estrutura sem entender como eles podem ser abusados. Vamos ver alguns exemplos.

ASP.NET ligação do modelo MVC

Nas aplicações MVC, a vinculação do modelo é o mecanismo que mapeia os valores de entrada ou JSON para propriedades de objeto. Por exemplo, imagine que você tem um aplicativo de lista “fazer” que tem uma classe ToDoItem com duas propriedades: ItemId e ItemDescription. A vinculação do modelo irá pesquisar automaticamente as entradas (digitações de formulário, parâmetros e parâmetros de sequência de consulta) para valores itemId e itemDescription e mapeá-los para uma instância do ToDoItem. Se houver um serviço REST para a lista, você pode passar em um ItemId e ItemDescription com seus respectivos valores, e tudo apenas funciona quando chega ao seu controlador.

Agora imagine um aplicativo que tenha usuários normais e usuários administrativos que são instâncias de uma classe de Usuário. A propriedade IsAdmin determina se um usuário é um administrador ou não. Se o método do controlador tomar um objeto usuário como argumento, então a vinculação do modelo fará sua mágica. Só que desta vez, é perigoso. Mesmo que o valor isAdmin não seja devolvido à interface do usuário, um invasor pode interceptar a solicitação e adicionar um simples “IsAdmin: True” à carga JSON enviada ao servidor. A vinculação do modelo encontra a propriedade IsAdmin no objeto, mapeia o valor e, assim, o invasor é um administrador em seu site.

A atenuação dessa ameaça é bastante simples. Use modelos de exibição para se comunicar de um lado para o outro do cliente e do servidor. Os modelos de exibição detêm apenas os dados necessários para a operação atual, não todos os dados em um objeto de domínio. O método controlador toma um objeto UserViewModel como argumento e a propriedade IsAdmin não está lá. Agora, quando o invasor adiciona o par de tecla/valor IsAdmin à solicitação, ele não se torna um administrador.

Entenda seus padrões

C# a segurança está entrelaçada com a estrutura .NET na maior parte do tempo. A grande coisa sobre ter uma estrutura que te apoia é que existem muitos padrões sensíveis que ajudam você a se manter seguro. Agora que ASP.NET Core 2.0 foi lançado, a estrutura faz ainda mais para você. É seu trabalho como desenvolvedor entender quais padrões existem e como garantir que eles não sejam comprometidos.

Se você está usando ASP.NET MVC, então você provavelmente está usando o Razor View Engine. O comportamento padrão do Razor é codificar todos os HTML e JavaScript para evitar ataques de scripting cross-site (XSS). No entanto, cuidado com o? HtmlString datas tipos e o? Html.Método bruto que renderizará HTML bruto sem codificar. Qualquer uso destes deve ser examinado de perto ou mesmo não permitido. ASP.NET Core permite que você anote os métodos de controlador que retornam HTML para que você possa acompanhar melhor quais métodos podem ser perigosos.

ASP.NET MVC também possui grande proteção de falsificação de solicitações embutidas (CSRF). Simplesmente anotar métodos de controlador com? ValidarAntiForgeryToken,? e a estrutura lida com os detalhes. ASP.NET Core tornou ainda mais fácil. Agora você pode adicionar um? Filtro AutoValidateAntiforgeryTokenAttribute no filtro? Configure O método Services para adicionar automaticamente a proteção CSRF a todos os métodos de controlador que precisem dele.

A questão é a seguinte: faça a pesquisa sobre a estrutura e as ferramentas que você está usando e sobre como eles podem proteger seus usuários. Use as ferramentas fornecidas para criar aplicativos seguros e criar padrões para todos os desenvolvedores da equipe seguirem. Seus aplicativos serão muito mais seguros apenas entendendo o que o framework .NET fornece e usando-o efetivamente.

C# Princípio de Segurança #2: Nunca role sua própria criptografia

Há uma verdade de segurança que 99% dos desenvolvedores devem levar a sério: você não sabe como fazer um algoritmo criptográfico seguro. Ficaria surpreso com quantas equipes de desenvolvimento de software tentam criar seu próprio algoritmo criptográfico. Não seja um deles. Atenha-se aos algoritmos que resistiram ao teste do tempo e ao escrutínio de especialistas em criptografia.

A estrutura .NET é seu amigo aqui também. Existem muitas implementações de frameworks .NET de algoritmos de criptografia fortes. Escrevi vários posts sobre criptografia para aqueles que querem um mergulho profundo em quais algoritmos usar e por quê. Basta dizer por enquanto que você quer AES para proteger dados confidenciais que repousam em seu banco de dados. O framework .NET tem implementações de AES para uso por desenvolvedores para que você não precise tentar criar o seu próprio.

API de proteção de dados

A versão .NET Core 2.0 trouxe mais guloseimas para os desenvolvedores no domínio da criptografia. A Microsoft adicionou a API de Proteção de Dados para tornar ainda mais fácil para os desenvolvedores usar criptografia forte para proteger seus dados. Eu pessoalmente amo essa API porque ela foi projetada bem de uma perspectiva de segurança e uma perspectiva de API. Com essa API, quando você precisa criptografar dados, basta passar os dados para o? Proteger o método. Quando você precisa acessar os dados novamente, basta passar os dados criptografados para o? Método de desprotetor, e ele voltou para o texto simples.

Esta API é ótima porque é simples e abstrata com sucesso todos os trabalhos internos longe dos desenvolvedores. Por padrão, ele usa criptografia AES de 256 bits para proteger dados, que é uma das melhores opções para um algoritmo. Quando você criptografa dados, o gerenciamento de chaves se torna uma preocupação. A API de proteção de dados lida com tudo isso para você, incluindo teclas rotativas regularmente. Os desenvolvedores não têm que se preocupar com os detalhes, apenas quais métodos chamar e quando.

C# Princípio de Segurança #3: Automatizar, Automatizar, Automatizar

Para que qualquer programa de segurança C# seja bem sucedido, você precisa entregar o código rapidamente enquanto ainda tem confiança na segurança do seu código. Há cada vez menos tolerância para pessoas de segurança pararem todo o desenvolvimento para executar revisões do código. A automação é a chave para fornecer código seguro rapidamente.

Existem duas maneiras de construir automação em segurança. Primeiro, crie casos automatizados de teste de segurança que podem ser executados a cada compromisso e construção. Esses testes verificam se os controles básicos de segurança estão no lugar. Escreva um teste que tente um ataque CSRF, e certifique-se de que não funciona. Teste seus mecanismos de autenticação e autorização para ter certeza de que eles são sólidos. Especialmente com os serviços REST, certifique-se de que você está devolvendo códigos de erro HTTP como 401 e 403 para que você possa testar e provar claramente que esses controles estão funcionando. Escreva testes que verifiquem se há cabeçalhos, como Política de Segurança de Conteúdo ou HSTS. Essas verificações simples podem tornar a segurança uma parte diária do seu ciclo de desenvolvimento. Se sua compilação falhar por causa de um dos testes falhar, você saberá imediatamente e corrigirá o bug antes que ele atinja a produção.

Em segundo lugar, você pode trazer a automação ainda mais “esquerda” para o ciclo de vida do desenvolvimento usando ferramentas que se integram diretamente ao IDE do desenvolvedor. O projeto Roslyn permite que as equipes criem analisadores de código que encontrarão problemas enquanto os desenvolvedores escrevem código. Use-as para criar regras personalizadas para o seu aplicativo.

Claro, isso pode ser um trabalho intensivo. Então, em vez disso, use ferramentas pré-construídas que você não precisa escrever a si mesmo. Uma dessas ferramentas é o CodeIt.Right do SubMain,que fornece ótimas dicas para os desenvolvedores à medida que eles codificam. Essas dicas incluem muitas práticas recomendadas de segurança, bem como diretrizes gerais de codificação. Você também pode personalizar CodeIt.Right com suas próprias regras, incluindo regras de segurança. Quando você faz a pesquisa que falei anteriormente para encontrar diretrizes de segurança para sua equipe, incorpore-as no CodeIt.Right para ajudar a educar os desenvolvedores à medida que eles codificam.

Atire por Princípios, Não Leis

As leis são regras duras e rápidas que você deve seguir. Princípios são verdades e práticas de alto nível que guiam suas decisões todos os dias. Uma regra é “Não devolva dados fornecidos pelo usuário ao cliente sem codificação”. Por outro lado, os princípios fornecerão uma base forte sobre a qual construir seu programa de segurança C#, independentemente de quais ataques específicos você precisa para proteger sua aplicação.

Os três princípios que cobrimos aqui são

  • Entenda sua estrutura.
  • Não tente criar sua própria criptografia.
  • Automatize suas práticas de segurança (incluindo as regras) o máximo possível.

Quando você estabelecer e seguir princípios como estes, você vai se preparar para o sucesso, não importa qual aplicativo você está construindo.

Saiba mais como o CodeIt.Right pode ajudá-lo a automatizar revisões de código e melhorar a qualidade do seu código.

Autor: Justin Boyer

Artigo Original