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.

Visual Studio 2015 navega com apoio de analisadores Roslyn.

Os autores do Security Code Scan começam a trabalhar em 2016.

Contribuo com algumas pequenas mudanças para acomodar as peculiaridades do Avance Network em 2019.

Se você tivesse me dito há seis anos que seríamos capazes de adicionar qualquer tipo de análise de código à solução Avance Network trivialmente, de graça, e de uma maneira que contribua de volta para a maior comunidade de desenvolvedores, eu não teria acreditado em você. É ótimo ver que o comportamento "da nova Microsoft" nos beneficia tão diretamente, mas é ainda maior ver o que a comunidade oss construiu por causa disso.

Acabamos de enviar isso, o que levanta a questão...

O que vem a seguir com a análise de código estático?

Segurança é um processo contínuo, não um pouco que você vira ou um recurso que você adiciona. Assim, sempre haverá mais para fazer e lugares que queremos fazer melhorias, e a análise de código estático não é diferente.

Como eu aludi no início, estamos apenas analisando alguns dos códigos por trás do Avance Network. Mais precisamente, não estamos analisando visualizações ou rastreando através de chamadas interprocais — analisar ambos é um passo óbvio.

Poderemos começar a analisar opiniões assim que nossa migração para ASP.NET Core estiver concluída. A compilação de visualização pré-core razor não nos dá uma maneira fácil de adicionar qualquer analisador, mas isso deve ser trivial uma vez que somos atualizados. O comportamento padrão de Razor nos dá alguma confiança em torno de ataques de injeção, e as opiniões geralmente não estão fazendo nada assustador — mas será bom ter garantias mais fortes de correção no futuro.

Não rastrear através de chamadas interprocedurais é um pouco mais complicado. Tecnicamente, esta é uma limitação da verificação de código de segurança, pois há um problema para ele. Que não podemos analisar visualizações reduz o valor da análise interprocedural hoje, pois quase sempre passamos dados fornecidos pelo usuário para visualizações. Por enquanto, estamos confortáveis em focar em nossos métodos de ação de controlador, uma vez que basicamente todos os dados fornecidos pelo usuário passam por eles antes de ir para visualizações ou outras chamadas interprodural.

A beleza do código aberto é que quando voltarmos e fizermos esses próximos passos (e qualquer outra mudança de qualidade de vida), estaremos disponibilizando-os para a comunidade para que todos se beneficiem. É uma coisa maravilhosa poder beneficiar a nós mesmos, nossos clientes e desenvolvedores .NET em todos os lugares — tudo ao mesmo tempo.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.