Insegurança demonstrada por exemplos evidencia a necessidade de um WAF

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

O aprendizado online está em alta. Especialmente entre aqueles que se consideram desenvolvedores. Se você der uma olhada na pesquisa anual do Stack Overflow com desenvolvedores (que recebe dezenas de milhares de respostas), verá que boa parte dos desenvolvedores não tem formação acadêmica na área:

• Entre os desenvolvedores profissionais que atuam atualmente em todo o mundo, 76,5% dos entrevistados afirmaram ter bacharelado ou um grau acadêmico superior, como mestrado ou equivalente.
• 20,9% disseram ter se formado em outras áreas, como negócios, ciências sociais, ciências naturais, engenharias não relacionadas à computação ou artes.
• Entre os desenvolvedores profissionais atuais, 32% disseram que sua formação acadêmica não foi muito importante ou não teve nenhuma importância para o sucesso de suas carreiras. Isso não é de todo surpreendente, considerando que 90% dos desenvolvedores, de modo geral, consideram-se pelo menos parcialmente autodidatas: um diploma formal é apenas um aspecto de sua formação, e grande parte do trabalho prático cotidiano depende das decisões específicas de suas empresas quanto à stack de tecnologia.

Observe o trecho destacado nos resultados da pesquisa. Eu poderia escrever uma tese sobre por que isso é verdade, mas basta dizer que, quando eu cursava a graduação, programava em Pascal, C++ e LISP. Meu primeiro emprego de verdade como desenvolvedor exigia C/C++, então, nesse aspecto, eu estava bem preparado. Mais tarde, porém, precisei aprender Java. E SQL. Não voltei à faculdade para isso. Recorri a livros, arquivos de ajuda e qualquer outra documentação que conseguisse encontrar. Ser autodidata é a norma, independentemente de você ter formação acadêmica ou não, porque a tecnologia muda e os profissionais não têm tempo de voltar à faculdade só para aprender uma nova linguagem ou framework.

Suspeito que isso não seja nada incomum para nenhum de nós. Não voltamos à faculdade para aprender uma nova CLI ou API. Não nos matriculamos em um novo curso superior só para aprender Python ou Node.js. Recorremos a livros, conteúdos na Internet e comunidades, e dependemos muito de “códigos de exemplo”.

Eu ainda recorro a blogs e à documentação, não apenas dos nossos próprios engenheiros e arquitetos, mas também de outras pessoas. Porque começar um doutorado agora não vai realmente me ajudar a aprender* todos os detalhes do framework Express ou do JQuery.

Não surpreende, portanto, que os engenheiros de rede e as equipes de operações (que, por constituírem a primeira parte da segunda onda de DevOps, serão doravante conhecidos como NetOps) também recorram aos mesmos tipos de materiais para adquirir as habilidades necessárias para dominar as ferramentas e tecnologias exigidas. Para quem está chegando agora, estamos falando de linguagens de script e APIs. E eles também, sem dúvida, copiarão e colarão à vontade à medida que se familiarizarem com a linguagem e os sistemas, começando a automatizar o pipeline de produção.

E assim chegamos ao motivo pelo qual escrevo hoje: código de exemplo.

Há muito código desse tipo por aí. E é um bom código — não saia daqui pensando que não sou grato ou que não valorizo códigos de exemplo. Eles são um recurso inestimável para quem está tentando aprender novas linguagens e APIs. O que vou criticar é a desconexão entre os códigos de exemplo e a segurança, algo que precisa ser resolvido. Afinal, ao ensinarmos iniciantes a programar, também deveríamos incutir neles pelo menos uma consciência sobre segurança, em vez de simplesmente ignorá-la.

Digo isso porque a segurança de aplicativos não é — repito, NÃO é — opcional. Eu poderia citar uma estatística atrás da outra, mas espero que, a esta altura, eu esteja falando para quem já está convencido. A segurança de aplicativos não é opcional, e é importante disseminar essa mentalidade até que ela seja vista como parte integrante do desenvolvimento. E não apenas de aplicativos, vale lembrar, mas também dos scripts e sistemas que viabilizam a automação nas mãos das equipes de DevOps e NetOps.

Apresento este exemplo como a fonte da minha angústia.

O código em si é lindo. Sério. Bem formatado, com bom espaçamento. Legível. Eu adoro esse código. Exceto pela parte que viola completamente a Regra Zero de Segurança.

JAMAIS CONFIE EM DADOS FORNECIDOS PELO USUÁRIO. EM HIPÓTESE ALGUMA.

Fico decepcionado por não haver sequer uma menção à necessidade de sanitizar a entrada. Nem nos comentários, nem no texto do artigo. O código simplesmente repassa “username” para outra função sem demonstrar a menor preocupação com a possibilidade de esse valor conter conteúdo malicioso.

Mas, Lori, obviamente este código serve para ilustrar a implementação de algo que não foi projetado para realmente entrar em produção. Não há risco.

Essa não é a questão. A questão é que, se continuarmos ensinando as pessoas a programar, deveríamos pelo menos tentar ensiná-las a fazer isso com segurança. Devemos mencionar isso com a mesma naturalidade com que explicamos a quem está começando a desenvolver em C/C++ que, se você não alocar memória para um ponteiro antes de acessá-lo, o programa vai travar.

Eu poderia escrever post após post com exemplos de como a segurança e o SDLC recebem apenas atenção da boca para fora, mas, quando chega a hora de tratar do que realmente importa e ensinar as pessoas a programar, a segurança de repente fica isolada em um canto, cercada por um campo SEP (problema de outra pessoa).

Esse é apenas mais um motivo pelo qual os firewalls de aplicações web são um componente essencial de qualquer estratégia de segurança de aplicações. As organizações precisam de uma barreira entre as entradas dos usuários e as aplicações que as aceitam cegamente como legítimas, para evitar se tornarem as mais recentes vítimas de uma longa lista de falhas de segurança em aplicações.

Porque, por mais que gostemos de falar sobre como tornar o código seguro, quando realmente ensinamos isso a outras pessoas, não praticamos o que pregamos. Precisamos estar mais atentos a essa falta de cuidado com a segurança — até mesmo em códigos de exemplo, pois é com eles que os desenvolvedores (e, cada vez mais, as equipes de NetOps) aprendem —, mas, enquanto não começarmos a fazer isso, precisamos de soluções de segurança como o WAF para preencher as lacunas deixadas por códigos inseguros.

* Ou inglês, pelo visto. Ah, qual é, eu faço isso de propósito. Porque às vezes é divertido falar errado.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie