Protegendo a web (e avançando)

Passamos a esperar um nível razoável de privacidade e segurança ao usar serviços e aplicativos baseados na web. Afinal, esses serviços fazem parte de todos os aspectos da nossa vida cotidiana — do dinheiro e das finanças à forma como interagimos com os serviços do governo, passando pela nossa educação ou a dos nossos filhos, pela comunicação com amigos e familiares, pelos cuidados com a saúde e até pela simples compra de alimentos. Já vimos as consequências drásticas das falhas de segurança, desde vazamentos de senhas em larga escala até a disseminação de malware, spyware e ransomware. Nos últimos anos, tenho dedicado boa parte do meu tempo ao tema da privacidade do usuário. Ao interagirmos com todos esses serviços, precisamos saber que os controles de privacidade e segurança adequados estão sendo aplicados. Em termos básicos, isso significa conexões criptografadas (por exemplo, usando HTTPS). Também significa proteger corretamente os dados armazenados e usar algoritmos de segurança e criptografia de forma adequada.

Em 2014, organizei um workshop do setor sobre como fortalecer a internet contra a ameaça da vigilância generalizada, que, entre outras coisas, defendia a adoção do HTTPS. Hoje, graças aos esforços de empresas, organizações e muitas pessoas, a grande maioria do uso da web acontece por HTTPS. Esse esforço do setor reconhece que a segurança é um pré-requisito para a privacidade. Você pode projetar um aplicativo que preserve a privacidade, mas, se ele não for desenvolvido e implantado em um ambiente seguro — e seus canais de comunicação não estiverem protegidos adequadamente até a interface do usuário —, ficará vulnerável a ataques. E agentes mal-intencionados exploram cada vez mais essa superfície de ataque. Basta observar a recente onda de ataques de phishing, malware e ransomware para perceber que temos um problema.

Além do transporte seguro

Agora que “resolvemos” (ou estamos a caminho de resolver) a questão do transporte seguro, quais são os outros pontos vulneráveis a ataques? No lado do servidor, há vulnerabilidades como o log4j, que agentes mal-intencionados têm usado para explorar endpoints de APIs Java. Também há vulnerabilidades no lado do cliente (por exemplo, vulnerabilidades de cross-site scripting) que ameaçam as interações com usuários em aplicativos web. As vulnerabilidades de cross-site scripting exploram as interações entre o ambiente JavaScript e o Document Object Model no navegador (ou na visualização web de um aplicativo empacotado). Esses ataques no lado do cliente podem expor dados privados do usuário a um invasor ou, pior ainda, executar ações em nome dele. Esse padrão é inerente ao funcionamento da web (e de muitos aplicativos). Queiramos ou não, vivemos em um mundo em que, com um único toque, podemos baixar e executar código de qualquer terceiro. Mesmo quando conhecemos e confiamos no terceiro em questão, o código dele ainda pode conter vulnerabilidades — especialmente quando é usado no mundo real, junto com códigos escritos por muitas outras pessoas. E, nos ataques de phishing, agentes mal-intencionados podem facilmente abusar da confiança dos usuários.

Cadeia de suprimentos de software

A maioria dos projetos de software depende de dependências. Gerenciadores de pacotes como o npm tentam facilitar o trabalho com elas. No NPM, o arquivo package.json descreve seu projeto, incluindo as dependências. Mas, como ele lista apenas as dependências diretas, sua ajuda para analisar toda a cadeia de suprimentos de software é limitada. Talvez desenvolvedores não estejam acostumados a pensar no desenvolvimento de software em termos de cadeia de suprimentos — um conceito, na verdade, emprestado da economia. (E, como já escrevi, alguns desenvolvedores podem torcer o nariz para essa terminologia.) Você pode estar se perguntando: “Agora todo desenvolvedor de software precisa virar especialista em segurança?” A resposta é sim, mais ou menos. Ou, pelo menos, desenvolvedores que trabalham com várias linguagens e em diferentes camadas precisam conhecer os fundamentos da segurança e começar a aprender mais.

Para começar a pensar na segurança das dependências de código aberto, um bom ponto de partida para desenvolvedores é o Guia conciso da OpenSSF para desenvolver software mais seguro. Essa lista de verificação inclui boas práticas básicas, como garantir que todos os desenvolvedores usem autenticação multifator ao enviar código, além de usar ferramentas de monitoramento e análise de vulnerabilidades que sugerem correções (como a ferramenta que a Snyk oferece).

Especificações avançadas de segurança

Outra fronteira da segurança de aplicativos web é o surgimento de APIs web que permitem recursos avançados com níveis extras de segurança. Por exemplo: a vulnerabilidade “Spectre” expôs aplicativos web que usavam SharedArrayBuffer a ataques no nível do processador, capazes de vazar dados entre contextos que normalmente seriam considerados seguros (de origens diferentes). Em resposta, a comunidade de padrões da web desenvolveu a cross-origin-opener-policy e a cross-origin-embedder-policy. Esse é um exemplo de várias novas especificações e APIs desenvolvidas em diferentes lugares para aumentar a segurança de APIs web avançadas e mitigar esses tipos de ataque. No entanto, devido à complexidade do problema e à sofisticação de algumas dessas abordagens (por exemplo, configurar cabeçalhos HTTP no caso de COOP e COEP), ainda é difícil conscientizar desenvolvedores sobre essas especificações.

Uma citação de um desenvolvedor, incluída na pesquisa MDN Web DNA de 2020, resume bem a questão:

Embora eu ainda esteja no começo da minha jornada na programação, a segurança... na internet continua sendo minha principal preocupação. Pessoalmente, acho que o jargão complexo usado para explicar como a segurança na web funciona hoje torna o aprendizado e a aplicação das melhores práticas de segurança uma das coisas mais difíceis para quem está começando a programar, mesmo quando se recorre a opções de terceiros.

Precisamos fazer um trabalho melhor para ajudar desenvolvedores web a aplicar as melhores práticas de segurança.

O que temos aqui…

Uma coisa ficou clara para mim, por estar com um pé na comunidade de desenvolvedores web e outro na comunidade de DevSecOps: precisamos nos comunicar mais. Desenvolvedores web precisam adotar a mensagem e a mentalidade sobre a cadeia de suprimentos de software (dependências) e colocar a análise de segurança em primeiro plano. A comunidade de desenvolvimento que já presta atenção às questões de segurança precisa levar essa mensagem a mais desenvolvedores e considerar os riscos de segurança para os usuários finais (como a privacidade), que ajudam a explicar por que a abordagem DevSecOps é tão importante.

Desenvolvedores web precisam participar das conversas sobre segurança — não apenas consumir as soluções. Gostaria de ver mais desenvolvedores web trabalhando conosco na OpenSSF. Por exemplo, no grupo de trabalho de melhores práticas da OpenSSF, estamos criando um conjunto de diretrizes para as melhores práticas de configuração de plataformas de gerenciamento de código-fonte (por exemplo, Github e Gitlab), entre outros temas. Outro exemplo são os cartões de pontuação da OpeSSF, que avaliam aspectos relacionados à segurança em repositórios de código aberto. Temos sentido falta das vozes da comunidade de desenvolvimento web nessas conversas. Como essa comunidade tende a se preocupar mais com questões de privacidade do usuário, esses temas têm recebido menos destaque no trabalho da OpenSSF do que deveriam, na minha opinião. Esse é um dos motivos pelos quais trabalhei para organizar um workshop do setor que reunisse essas comunidades para “avançar na proteção da web”.

O workshop acontecerá em Londres, nos dias 7 e 8 de junho, e será aberto ao setor. A ideia é reunir algumas dessas vozes e, com sorte, impulsionar novos trabalhos. O prazo para enviar propostas ao workshop vai até 24 de abril. Desenvolvedores web que se preocupam com segurança também poderão participar.