Como conseguimos esta história é interessante e também ilustrativa dos avanços em comunidade de código aberto da NET….

Mas primeiro…

 

O que tínhamos antes da análise estática?

 

A base de código Avance Network está em desenvolvimento contínuo há cerca de uma década, começando todo o caminho de volta em ASP.NET MVC Preview 2. Como o .NET avançou, adotamos ferramentas que incentivam práticas seguras como o Razor (que não codifica strings, ajudando a proteger contra vulnerabilidades de scripting de sites cruzados). Também criamos novas ferramentas que incentivam fazer as coisas do Caminho Certo™, como o Dapper, que lida com a parametrização sql automaticamente enquanto ainda é umORM incrivelmente performático (lite-).

 

Uma lista incompleta, mas ilustrativa, de padrões seguros para padrões padrão em nossa base de código:

 

Parametrização automatizada de SQL com Dapper

 

Cordas de codificação padrão em visualizações com Razor

 

Exigir tokens de falsificação de solicitações de sites cruzados (XSRF) para tokens não-idempotentes (ou seja. POSTAR, COLOCAR, EXCLUIR, etc.) rotas por padrão

 

HMACs com expirações padrão e código de validação comum

 

Adotando o TypeScript — um processo contínuo — que aumenta nossa confiança em torno do javaScript correto de envio

 

Dados privados — para equipes e empresas — estão em infraestrutura separada com controles de acesso separados

 

Estávamos seguros, pelo menos em teoria, da maioria das classes de injeção e ataques de scripting crosso-site.

 

Então…

 

O que a análise estática nos deu?

 

Em grande parte, a confiança de que estávamos consistentemente seguindo nossas melhores práticas pré-estabelecidas. Embora nossos engenheiros sejam talentosos e nossas ferramentas sejam fáceis de usar, tivemos dezenas de pessoas trabalhando no Avance Network por mais de 10 anos — inevitavelmente, alguns erros caíram na base de códigos. Assim, a maioria das correções estavam apenas se movendo para fazer algo “do jeito certo” e muito menor. Coisas como “use nosso atributo de registro de rota em vez de [HttpPost]” ou “remova os usos antigos do SHA1 e mude para SHA256”.

As correções mais “emocionantes” exigiam a introdução de novos padrões e a atualização de códigos antigos para usá-los. Embora não estivéssemos sem provas de que qualquer um deles fosse explorado, ou mesmo explorável na prática, achamos que era melhor errar no lado da cautela e abordá-los de qualquer maneira. Adicionamos três novos padrões como parte da adoção da análise de código estático:

 

Substituímos os usos do System.Random por uma interface equivalente apoiada pelo System.Security.Cryptography.RandomNumberGenerator. É muito difícil provar que um número aleatório sendo previsível ou é ou não seguro, então padronizamos sempre difícil de prever.

Agora, não podemos proibir redirecionamentos HTTP para domínios que não controlamos, exigindo que todas as exceções sejam explicitamente documentadas. A preocupação aqui são redirecionamentos abertos,que podem ser usados para phishing ou outros propósitos maliciosos. A maioria dos nossos redirecionamentos já estava validando isso, mas as verificações foram espalhadas pela base de código. Houve alguns cheques perdidos ou de buggy, mas não encontramos nenhuma evidência deles sendo explorados.

Reforçamos as verificações do XSRF para explicar os casos em que os usuários se deslocam entre estados não autenticados e autenticados. Nossas verificações XSRF anteriormente assumiram que havia um único token vinculado à identidade de um usuário. Uma vez que isso muda durante a autenticação, parte do nosso código suprimiu essa verificação e se baseou em outra validação (completar um fluxo OAuth, por exemplo). Embora todos os casos tenham tido algum tipo de prevenção xsrf, ter qualquer opt-outs do nosso código de verificação padrão XSRF é arriscado. Então decidimos melhorar nossos cheques para lidar com este caso. Nossa solução era permitir que dois tokens fossem aceitáveis, brevemente, em certas rotas.

Nossas verificações são executadas em todas as RP para Avance Network e, adicionalmente (e explicitamente), em cada construção da Enterprise — o que significa que não estamos apenas confiantes de que estamos seguindo nossas melhores práticas hoje, estamos confiantes de que continuaremos a segui-las no futuro.

Em termos de listas OWASP (Open Web Application Security Project, projeto de segurança de aplicativos da Web Aberta), ganhamos detecção automática de:

 

 

Ataques de injeção de SQL [2017 #1]

 

Ataques de entidade externa XML (XEE)[2017 #4]

 

Ataques de scripting cross site (XSS)[2017 #7]

 

Deserialização insegura [2017 #8]

 

Ataques XSRF [2013 #8]

 

Redirecionamentos abertos [2013 #10]

 

Isso encerra o que encontramos e consertamos, mas…

 

Como adicionamos análise de código estático?

 

Isso é chato porque tudo o que fizemos foi escrever um arquivo de config e adicionar uma Referência de pacote ao SecurityCodeScan.

É isso, é isso. Visual Studio irá pegá-lo como um analisador (para que você obtenha squigglies) e o compilador C# fará o mesmo para que você receba avisos ou erros conforme desejado.

 

 

Muito mais interessante é todas as coisas de código aberto que tornaram isso possível:

 

Em 2014, a Microsoft criou roslyn, seu compilador C# e VB.NET.

&n