Skip to main content

Usar um ciclo de vida de desenvolvimento seguro

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:

  • Explicar a importância de proteger o ciclo de vida de desenvolvimento.
  • Listar ataques proeminentes (injeção, XSS) que se aproveitam da falta de higienização e validação.

Proteger o ciclo de vida do desenvolvimento de software

  1. Planejar quais requisitos e casos de uso um aplicativo vai resolver.
  2. Criar o aplicativo.
  3. Codificar a implementação do aplicativo.
  4. Testar se o aplicativo está funcionando corretamente.
  5. Implantar o aplicativo no cliente.
  6. Manter o aplicativo.

Uma corrente com cada elo correspondendo ao ciclo de vida de desenvolvimento de software. São seis elos: planejar, criar, codificar, testar, implantar e manter

A lista anterior mostra as seis etapas de um ciclo de vida de desenvolvimento de software (SDLC, Software Development Lifecycle) típico. Se você já trabalhou em uma equipe de desenvolvimento de aplicativos antes, provavelmente conhece cada fase desse ciclo. Mas o que você pode não saber é onde entra o papel dos engenheiros de segurança de aplicativos. Eles basicamente testam a segurança do aplicativo antes de ser implantado no cliente? Eles se concentram em manter a segurança do aplicativo aplicando patches em vulnerabilidades críticas? Ou sugerem a incorporação dos recursos de segurança na criação? 

A resposta é que os engenheiros de segurança de aplicativos têm um papel crucial em cada etapa do SDLC. Como os problemas de segurança podem ser inseridos ou descobertos em qualquer fase do ciclo de vida de um aplicativo, os engenheiros de segurança de aplicativos precisam constantemente proteger a confidencialidade, a integridade e a disponibilidade dos dados do aplicativo. A segurança costuma ser vista como um problema de elo mais fraco. Assim como uma corrente de metal forte pode ser quebrada quando um elo é comprometido, cada fase do SDLC precisa ser protegida para garantir o desenvolvimento, a implantação e a manutenção do aplicativo como um todo. 

Uma corrente de metal quebrando por causa de um elo fraco

Por exemplo, durante a fase de implementação do SDLC, vulnerabilidades poderão aparecer no código se os desenvolvedores deixarem de fazer verificações para higienizar e validar as entradas. Isso poderia permitir que um invasor inserisse entradas no aplicativo que permitisse a ele acessar indevidamente os dados de outro usuário ou uma função administrativa. 

Além disso, as equipes de desenvolvimento costumam usar código-fonte aberto no desenvolvimento de aplicativos. O código-fonte aberto é desenvolvido colaborativamente por várias pessoas que trabalham juntas na internet. Embora esse código possa ser mais seguro devido ao grande número de desenvolvedores que trabalham juntos para desenvolvê-lo e revisá-lo, ele também pode conter vulnerabilidade às vezes. As equipes de desenvolvimento precisam manter a conscientização e verificar as bibliotecas de código para ter certeza de que não estão usando componentes com vulnerabilidades conhecidas. 

No mundo do desenvolvimento ágil, em que as equipes de desenvolvimento de aplicativos estão sempre lançando novos serviços e recursos em cronogramas cada vez mais apertados, a atenção à devida higiene cibernética e ao devido controle de alterações pode acabar um pouco negligenciada. 

Os engenheiros de segurança de aplicativos trabalham lado a lado com as equipes de desenvolvimento em todas as fases do SDLC. Eles atuam como defensores, consultores e especialistas no assunto para garantir o design seguro dos aplicativos, a implementação do código com validações de segurança e para impedir a introdução de vulnerabilidades entre as fases de desenvolvimento, garantia de qualidade e produção. 

Proteger contra injeção e Cross-Site Scripting (XSS)

Proteger o SDLC é particularmente importante para proteger contra dois riscos à segurança do aplicativo conhecidos e fáceis de explorar: injeção e Cross-Site Scripting (XSS). Pense na funcionalidade de um aplicativo. Um dos recursos mais importantes de quase todo aplicativo é a capacidade de armazenar e recuperar dados de um repositório de dados (por exemplo, um banco de dados). Os desenvolvedores usam linguagem de programação para dizer ao aplicativo como interagir com o banco de dados com base nas entradas dos usuários. Por exemplo, quando um usuário faz login em um aplicativo, ele insere o nome de usuário e a senha. Quando pressiona Enter, ele aciona uma consulta ao banco de dados e, quando a consulta é bem-sucedida, ele pode acessar o sistema. 

Infelizmente, cada interação que um usuário legítimo tem com um aplicativo também pode ser explorada por um invasor com intenções hostis. Uma falha de injeção ocorre quando um invasor envia dados não confiáveis como parte de um comando ou consulta. Se os desenvolvedores não validaram/higienizaram as entradas corretamente, um invasor pode executar comandos indesejados ou acessar dados sem a devida autorização. Isso pode levar à perda, à corrupção ou à divulgação dos dados. 

Parece bem assustador! Mas os engenheiros de segurança de aplicativos têm o incrível trabalho de garantir que isso não aconteça. Eles usam várias ferramentas e técnicas para ajudar a equipe de desenvolvimento a proteger o aplicativo e os dados de seus clientes desse tipo de ataque.

  • Revisão de código-fonte: um processo basicamente manual no qual os engenheiros de segurança de aplicativos leem parte do código-fonte para verificar a devida validação e higienização dos dados.
  • Teste estático: um método de teste de software que examina o código do programa, mas não exige sua execução durante o processo. Por exemplo, a análise de código estático pode verificar o fluxo de dados de entrada de um usuário não confiável em um aplicativo da web e verificar se os dados são executados como comando (o que é um resultado indesejável).
  • Teste dinâmico: um método de teste de software que examina o código do programa enquanto ele é executado.
  • Teste automático: usa scripts de teste para avaliar software comparando o resultado real do código com seu resultado esperado.
  • Separação de comandos e consultas: mantém os dados separados dos comandos e das consultas. O objetivo é que cada método seja um comando que realiza uma ação ou uma consulta que retorna dados ao chamador, nunca ambos. Uma consulta jamais deve alterar o estado de um aplicativo ou de seus dados e um comando pode alterar o estado, mas jamais deve retornar um valor. Isso impede que um invasor forneça comandos a um sistema operacional por meio de uma interface da web para executá-los e fazer upload de programas maliciosos ou obter senhas.
  • Listas de permissões: a implementação de listas de permissões de caracteres ou comandos permitidos pode validar a entrada do usuário e impedir que a URL e os dados de formulário executem comandos que usam esses caracteres ou executem comandos não permitidos. Por exemplo, uma lista de permissões pode escapar ou filtrar caracteres especiais, como ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , `
  • E mais: a Enumeração de vulnerabilidades comuns (CWE, Common Weakness Enumeration) da Mitre é um bom recurso para se levar em conta na proteção contra injeção de comandos.

Além da injeção, outro risco ao SDLC gerado pela falta de validação e higienização dos dados e de teste e revisão de código é a vulnerabilidade do aplicativo a Cross-Site Scripting (XSS). XSS ocorre quando um aplicativo inclui dados não confiáveis em uma nova página da web sem a devida validação. 

A imagem ilustra o fluxo de ocorrência de XSS. Primeiro, um invasor injeta código mal-intencionado em um site confiável para enviar esse código a um usuário desavisado. Segundo, a página da web salva o script mal-intencionado em um banco de dados. Em seguida, a vítima visita o site e solicita dados do servidor porque acha que ele é seguro. Os dados que contêm o script mal-intencionado são transmitidos pelo servidor da página da web para o computador do usuário e são executados. Por fim, eles fazem callback para o invasor, o que compromete as informações do usuário; enquanto isso, o usuário acredita que está interagindo em uma sessão online segura com um site confiável.  

Um invasor injetando código mal-intencionado em um site confiável para comprometer os dados de um usuário desavisado em um ataque de XSS

Com a execução de scripts mal-intencionados no navegador de uma vítima usando XSS, um agente hostil pode sequestrar a sessão do usuário, adulterar um site ou redirecionar o usuário a um site mal-intencionado para baixar malware ou inserir credenciais que serão roubadas pelo invasor. O resultado pode ser o computador da vítima ser infectado com malware, seus dados confidenciais serem roubados ou o computador passar a fazer parte de botnets que o invasor pode usar para fazer ataques de negação de serviço distribuídos, que inundam a rede de uma organização com tráfego e limitam o acesso de usuários legítimos. 

Os engenheiros de segurança de aplicativos precisam se preocupar com XSS porque é um vetor de ataque facilmente explorável e é uma vulnerabilidade de segurança difundida que os hackers podem aproveitar por meio de ferramentas automatizadas e disponíveis gratuitamente. 

Há estimativas de que existe vulnerabilidade a XSS em dois terços de todos os aplicativos. Embora isso pareça assustador, também significa que os engenheiros de segurança de aplicativos têm um papel empolgante e importante na segurança do SDLC. Com isso, os engenheiros garantem a validação da entrada do usuário no aplicativo e evitam o armazenamento de entradas não higienizadas que podem ser exibidas mais tarde por outro usuário ou administrador. Isso é alcançado pela separação de dados não confiáveis do conteúdo de navegador ativo com o uso de estruturas de código que escapam XSS automaticamente por design e com a aplicação de programação sensível ao contexto.

Resumo

Você aprendeu várias considerações importantes que ajudam a proteger os aplicativos e seus dados ao longo do SDLC. Agora é hora de saber mais sobre outra consideração essencial para engenheiros de segurança de aplicativos: a devida configuração dos componentes de aplicativo.  

Recursos

Compartilhe seu feedback do Trailhead usando a Ajuda do Salesforce.

Queremos saber sobre sua experiência com o Trailhead. Agora você pode acessar o novo formulário de feedback, a qualquer momento, no site Ajuda do Salesforce.

Saiba mais Continue compartilhando feedback