A insegurança orientada por exemplos ilustra a necessidade de WAF

Aprender on-line é importante. Especialmente para aqueles que se identificam como desenvolvedores. Se você der uma olhada na pesquisa anual de desenvolvedores do Stack Overflow (na qual eles recebem dezenas de milhares de respostas), você encontrará uma boa parcela de desenvolvedores que não são formalmente treinados:

• Entre os atuais desenvolvedores profissionais em todo o mundo, 76,5% dos entrevistados disseram ter um diploma de bacharel ou superior, como um mestrado ou equivalente.
• 20,9% disseram que se formaram em outras áreas, como negócios, ciências sociais, ciências naturais, engenharia não computacional ou artes.
• Dos atuais desenvolvedores profissionais, 32% disseram que sua educação formal não era muito importante ou nada importante para seu sucesso profissional. Isso não é totalmente surpreendente, dado que 90% dos desenvolvedores em geral se consideram pelo menos um pouco autodidatas : um diploma formal é apenas um aspecto de sua educação, e grande parte de seu trabalho prático diário depende das decisões individuais de cada empresa sobre o conjunto de tecnologias.

Observe a parte destacada dos resultados da pesquisa. Eu poderia escrever uma tese sobre o porquê disso ser verdade, mas basta dizer que quando eu estava estudando para minha graduação, eu escrevia em Pascal, C++ e LISP. Meu primeiro emprego de verdade como desenvolvedor exigia C/C++, então eu era bom nisso. Mas depois fui obrigado a aprender Java. E SQL. Não voltei para a escola para fazer isso. Recorri a livros, arquivos de ajuda e qualquer outra documentação que consegui. Autodidata é a norma, quer você tenha educação formal ou não, porque a tecnologia muda e os profissionais não têm tempo para voltar à escola apenas para aprender uma nova linguagem ou estrutura.

Suspeito que isso não seja incomum para nenhum de nós. Não voltamos à escola para aprender uma nova CLI ou API. Não nos inscrevemos em um novo curso apenas para aprender Python ou Node.js. Recorremos a livros e conteúdos na Internet, a comunidades e confiamos fortemente em “código de exemplo”.

Ainda confio em blogs e documentação, não apenas de nossos próprios engenheiros e arquitetos, mas de outras pessoas também. Porque me inscrever para um doutorado agora não vai me ajudar a aprender* os detalhes do framework Express ou do JQuery .

Não é nenhuma surpresa, então, que engenheiros e operações de rede (que, sendo a parte da primeira parte da segunda onda do DevOps, doravante serão conhecidos como NetOps) também provavelmente recorrerão aos mesmos tipos de materiais para obter as habilidades necessárias para serem proficientes com as ferramentas e tecnologias necessárias. Isso é linguagens de script e APIs, para quem está começando a entender. E eles também, sem dúvida, copiarão e colarão com todo o coração à medida que se familiarizarem com a linguagem e os sistemas que começam a automatizar o pipeline de produção .

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

Há muito disso. E é um bom código, não vá embora pensando que eu não sou grato ou não valorizo o código de exemplo. É um recurso inestimável para qualquer pessoa que esteja tentando aprender novas linguagens e APIs. O que vou reclamar é que há uma desconexão entre o código de exemplo e a segurança que precisa ser abordada. Porque, ao mesmo tempo em que ensinamos novas pessoas a programar, também deveríamos incutir nelas pelo menos uma consciência sobre segurança, em vez de ignorá-la descaradamente.

Digo isso porque a segurança do aplicativo não é – repito, NÃO é – opcional . Eu poderia lançar estatística após estatística após estatística, mas espero que neste ponto eu esteja pregando para convertidos. A segurança de aplicativos não é opcional, e é importante disseminar essa atitude até que ela seja vista como parte integrante do desenvolvimento. Não apenas aplicativos, veja bem, mas os scripts e sistemas que impulsionam a automação nas pontas dos dedos do DevOps e NetOps.

Apresento como fonte da minha angústia este exemplo. 

O código em si é lindo. Realmente. Bem formatado, bom espaçamento. Legível. Adoro esse código. Exceto a parte que viola completamente a Regra de Segurança Zero .

NÃO CONFIARÁS NAS INFORMAÇÕES DO USUÁRIO. SEMPRE.

Estou desapontado que não haja nem mesmo um aceno de cabeça para a necessidade de higienizar a entrada. Nem nos comentários nem no texto do artigo. O código apenas passa o “nome de usuário” para outra função sem nenhuma preocupação de que ele possa conter conteúdo malicioso.

Mas Lori, obviamente esse código tem como objetivo ilustrar a implementação de algo que não foi projetado para realmente entrar em produção. Não é um risco.

Não é essa a questão. A questão é que se continuarmos a ensinar as pessoas a programar, deveríamos pelo menos tentar ensiná-las a fazer isso de forma segura . Mencionar isso tão rotineiramente quanto alguém aponta para desenvolvedores iniciantes em C/C++ que se você não alocar memória para um ponteiro antes de acessá-lo, ele irá travar.

Eu poderia encher blog após blog com exemplos de como a segurança e o SDLC são tratados de boca para fora, mas quando se trata de detalhes e de ensinar as pessoas a programar, de repente ele fica sozinho em um canto com um campo SEP (problema de outra pessoa) ao redor.

Esta é apenas mais uma razão pela qual os firewalls de aplicativos web são um componente essencial para qualquer estratégia de segurança de aplicativos. As organizações precisam de uma barreira entre a entrada do usuário e os aplicativos que a aceitam cegamente como legítima para evitar se tornarem a mais nova vítima de uma longa lista de falhas de segurança em aplicativos.

Porque por mais que gostemos de falar sobre segurança de código, quando realmente o ensinamos aos outros, não colocamos em prática o que pregamos. Precisamos estar mais cientes dessa falta de atenção à segurança – mesmo em códigos de exemplo, porque é onde os desenvolvedores (e cada vez mais os NetOps) aprendem – mas até começarmos a fazer isso, precisamos de soluções de segurança como WAF para preencher as lacunas deixadas por códigos inseguros.
 

* Ou inglês, aparentemente. Ah, vamos lá, eu faço isso de propósito. Porque às vezes é divertido dizer errado.