Cinco perguntas a se fazer antes de criar um projeto web

Há um milhão de razões para o fracasso de projetos de tecnologia. Modelos de negócios mal calculados, demanda superestimada ou custos borbulhantes, você escolhe. Mas ao longo da minha vida profissional, vi alguns projetos com ideias brilhantes e bom potencial desmoronarem devido a erros e omissões aparentemente menores. E acho que esse motivo é o mais amargo de todos, pelo menos para mim como desenvolvedor. Neste artigo, quero compartilhar minha experiência e analisar os problemas e desafios que os desenvolvedores backend enfrentam ao trabalhar em aplicações web. Destacarei pontos-chave que muitas vezes são esquecidos e explicarei como enfrentar esses obstáculos com a máxima eficiência. Tenho certeza que isso irá ajudá-lo a minimizar os riscos e aumentar significativamente as chances de sucesso do seu projeto.

1. Existe algum segredo armazenado no seu código?

Não importa o quão óbvio possa parecer, este ponto é crucial: nunca armazene informações confidenciais ou sensíveis em seu código-fonte. As violações podem levar a perdas financeiras e outros problemas sérios. As informações confidenciais que nunca devem ser armazenadas no código incluem:

• Chaves de API e tokens de acesso a serviços internos ou externos
• Senhas e dados da conta, incluindo senhas do banco de dados e do sistema administrativo
• Chaves de criptografia
• Arquivos de configuração com dados confidenciais
• Respostas a perguntas de segurança, como nome de solteira da mãe ou nome do animal de estimação

Em vez de armazenar essas informações no código do seu projeto, use variáveis de ambiente. Para sistemas mais seguros, considere usar soluções robustas de armazenamento secreto, como Cofre HashiCorp . Gerenciador de segredos da AWS ou Segredos do GitHub também pode ser útil. A escolha de ferramentas de armazenamento secreto depende de fatores como tipo e tamanho do projeto, experiência da equipe e pilha de tecnologia.

Se você acha que armazenar informações confidenciais no código do aplicativo não é um problema sério, considere o seguinte: somente em 2022, o GitHub detectou mais de 1,7 milhão de segredos potenciais expostos em repositórios públicos. Imagine quantos desses dados podem existir em projetos privados onde os desenvolvedores desconhecem possíveis vazamentos até que eles ocorram.

Solução: verifique seu projeto agora mesmo

Se você já tem um projeto e agora está preocupado com os segredos do seu código, existem soluções úteis que podem lhe trazer tranquilidade. As verificações manuais podem ser demoradas, por isso a automação é fundamental. Ferramentas úteis incluem:

• TruffleHog : pesquisa segredos em repositórios Git verificando o histórico de commits em busca de chaves de API e outros dados confidenciais.
• GitLeaks : detecta segredos codificados como senhas, chaves de API e tokens em repositórios git.
• GitGuardian : opera em seu ambiente local ou de CI para encontrar mais de 350 tipos de segredos e outras vulnerabilidades de segurança.
• Segurança avançada do GitHub : verifica automaticamente os repositórios em busca de tipos conhecidos de segredos e alerta você se algum for encontrado.

Estas ferramentas são apenas alguns exemplos; outras opções populares incluem SonarQube e Checkmarx . Ambos oferecem soluções pagas e gratuitas para atender diversas necessidades e orçamentos. O objetivo aqui não é listar todas as ferramentas disponíveis, mas destacar a existência desses problemas e possíveis soluções. Reconhecer o problema é metade da batalha. Agora, é importante reservar tempo para resolver isso e escolher as ferramentas adequadas às suas necessidades.

2. O que você sabe sobre as licenças da sua biblioteca?

Surpreendentemente, este tópico raramente é discutido e alguns desenvolvedores nem sequer estão cientes de que o uso de soluções de terceiros pode levar a questões legais e problemas significativos para sua empresa. Não acredite em mim? Imagine este cenário: um desenvolvedor de uma pequena empresa inclui uma biblioteca distribuída sob o Licença Pública Geral GNU Affero (AGPL) em um produto web comercial. Como uma licença copyleft, a AGPL exige que qualquer software que utilize código lançado sob ela seja distribuído sob os mesmos termos. Isso significa que todo o código da sua aplicação web, incluindo desenvolvimentos exclusivos, deve estar aberto e disponível para uso e modificação gratuitos. Como nosso produto de exemplo é comercial, disponibilizar seu código-fonte poderia prejudicar gravemente a vantagem competitiva e o modelo de negócios da empresa.

Problemas sérios também podem surgir com projetos que utilizam bibliotecas com licenças que proíbem explicitamente o uso comercial. E não fica muito melhor se não houver nenhuma licença: na verdade, a ausência de uma licença representa um problema significativo, uma vez que qualquer código é protegido por direitos autorais por padrão. As licenças concedem aos usuários o direito de usar o código sob condições específicas, mas sem uma licença, não há base legal para usar o código, mesmo que seja acessível publicamente.

Vale a pena notar que as questões de licenciamento podem afetá-lo de diferentes maneiras, dependendo da sua jurisdição: este assunto é particularmente relevante para países que assinaram acordos internacionais de direitos autorais. Por exemplo, a Convenção de Berna para a Proteção das Obras Literárias e Artísticas, um dos principais tratados internacionais nesta área, conta atualmente com cerca de 180 países membros. Portanto, usar código sem permissão explícita significaria violar as leis de direitos autorais e poderia levar a batalhas legais em muitos lugares do mundo. No entanto, isso não significa que você deva se mudar para um país “confortável” apenas para violar todas as regras escritas e não escritas. Respeitemos uns aos outros, e se alguém não quer que seu desenvolvimento seja utilizado para determinados fins, é melhor não fazê-lo, mesmo do ponto de vista humano.

Solução: use verificações e atualizações automatizadas

Como você pode ver, as questões de licenciamento e direitos autorais são complexas. Para proteger você e sua empresa com antecedência, é melhor verificar as licenças das bibliotecas e softwares que você usa. Para bibliotecas, isso não é muito difícil; gerenciadores de pacotes modernos já possuem ferramentas para isso. Por exemplo, no PHP Composer, você pode fazer isso com o comando ` licenças de compositor `, em Python pip através de ` licenças pip `, e em Golang, você pode obter essas informações através de ` licenças go `.

E não se esqueça de chamar esses comandos ao atualizar dependências (é ainda melhor automatizar essas verificações), pois a licença de uma biblioteca conectada pode mudar em novas versões.

3. O acesso à sua versão de desenvolvimento é restrito?

No desenvolvimento web, é comum ter múltiplas versões de um projeto, como desenvolvimento (dev), garantia de qualidade (QA), preparação e produção. Frequentemente, encontrei cenários em que versões de desenvolvimento/controle de qualidade e de teste de um site ou projeto da Web eram acessíveis a qualquer pessoa na Internet. De forma alarmante, às vezes as versões de teste podem ser indexadas pelos motores de busca de forma mais eficaz do que a versão primária, o que geralmente prejudica o produto.

O principal problema aqui é que as versões de teste podem conter bugs ou informações confidenciais, talvez até comprometedoras. Além disso, as versões beta são normalmente mais vulneráveis a hackers do que a produção final. Isso significa que sua disponibilidade aumenta o risco de um invasor obter acesso a dados confidenciais, código interno ou até mesmo ao próprio servidor. Isso é especialmente verdadeiro se você estiver desenvolvendo um back-end para algo como um aplicativo móvel, pois o acesso não autorizado a versões de teste da API pode ser extremamente perigoso.

Além dos riscos de segurança, páginas da web duplicadas podem impactar negativamente as classificações dos mecanismos de pesquisa. Mecanismos de busca como o Google podem ver essas duplicatas como conteúdo indesejável, potencialmente diminuindo a classificação das páginas originais do seu projeto ou até mesmo removendo-as completamente do índice.

Solução: Elabore sua estratégia de segurança desde o início

Não economize em domínios. Se você precisar de uma versão de teste acessível online, adquira um domínio separado especificamente para ela. Essa medida simples, mas eficaz, reduz os riscos de segurança porque os invasores geralmente verificam primeiro os subdomínios. Hospedar sua versão de teste em qualquer subdomínio do recurso principal torna-a um alvo fácil.

Restrinja o acesso a todas as versões de teste. Certifique-se de que as versões de desenvolvimento, controle de qualidade, teste e outras versões não sejam acessíveis publicamente. Configure-os para serem acessíveis apenas através de uma VPN, por exemplo. Isto reduz a probabilidade de acesso não autorizado, mesmo que o domínio de teste se torne conhecido por agentes mal-intencionados.

Proteja as versões de teste contra indexação. Mesmo que suas versões de teste sejam acessíveis apenas via VPN e hospedadas em domínios secretos separados, proteja-as da indexação do mecanismo de pesquisa usando um arquivo `robots.txt` ou meta tags `noindex`. Esta etapa é crucial, pois às vezes os mecanismos de pesquisa podem encontrar e indexar essas páginas de maneiras inesperadas.

4. O seu endereço IP real está oculto? Suas portas não utilizadas estão fechadas?

Existem regras de segurança que muitos desenvolvedores tendem a ignorar, embora sejam extremamente importantes e tenham sido estabelecidas por meio de lições aprendidas com dificuldade. Uma dessas regras é sempre ocultar o endereço IP real do seu projeto. Se o endereço IP dos seus servidores puder ser determinado através do nome de domínio, isso poderá levar a vários problemas, como:

• Ataques DDoS: Conhecendo o endereço IP real do seu projeto, os invasores podem lançar um ataque de negação de serviço distribuída (DDoS) em seu servidor. Por exemplo, um Amplificação de reflexão DNS O ataque pode sobrecarregar seu servidor com um grande volume de respostas de servidores DNS públicos, tornando seu serviço indisponível para os usuários e causando perdas financeiras significativas.

  
  

• Identificação de vulnerabilidades potenciais: Hackers sérios, não apenas amadores, podem examinar portas abertas e software exposto na rede para encontrar e explorar pontos fracos. Mesmo serviços conhecidos como o MongoDB tiveram violações de dados significativas devido a configurações incorretas. Muitos desses problemas poderiam ser evitados simplesmente ocultando o endereço IP real.

Solução: torne a vida do potencial invasor mais complicada

Ao ocultar o endereço IP real do seu servidor, você torna muito mais difícil para os invasores atingirem o seu sistema. Usar uma rede de distribuição de conteúdo (CDN) ou serviços de proteção DDoS pode ser muito eficaz aqui. As opções populares incluem CloudFlare , que oferece recursos de CDN e proteção DDoS gratuitamente, bem como serviços como Imperva (anteriormente Incapsula) fornecendo funções semelhantes e QRator , especializada na proteção de aplicativos Web com um FIrewall de aplicativos Web, mas isso pode gerar custos.

Embora essas ferramentas possam melhorar significativamente a segurança, há considerações adicionais a serem lembradas:

• Vazamento de IP no cabeçalho do e-mail: se você usar seu servidor principal para enviar e-mails, o endereço IP real pode ser exposto nos cabeçalhos do e-mail, prejudicando seus esforços de segurança.

  
  

• Histórico de IP e solicitações Whois: serviços como Histórico de DNS ou Solicitação Whois pode revelar os endereços IP históricos associados a um domínio. Se o seu IP real já esteve vinculado ao seu domínio de trabalho, você deve alterá-lo.

  
  

• Proteção DDoS e endpoints de API: tenha cuidado ao usar a proteção DDoS para domínios que servem como endpoints de API. Os sistemas de proteção podem introduzir etapas de verificação do usuário que podem interromper o funcionamento dos seus aplicativos do lado do cliente, substituindo respostas JSON/XML por código HTML.

  
  

• Solicitações de API de saída: quando seu servidor envia solicitações para APIs de terceiros, ele pode revelar inadvertidamente seu endereço IP. Usar servidores proxy para tais solicitações pode ajudar, pois alterar um proxy é mais fácil do que lidar com as consequências de um ataque.

É importante lembrar que ocultar o endereço IP real do seu projeto não é uma medida panacéia. Fechar as portas usadas pelo seu software da rede externa é crucial sempre que possível. Alterar as portas padrão é uma prática discutível; alguns especialistas argumentam que isso complica sua configuração sem benefícios significativos. Freqüentemente, é preferível configurar o software para interagir por meio de soquetes Unix em vez de conexões TCP de rede (se o projeto e o software forem executados no mesmo servidor). Essa abordagem não apenas aumenta a velocidade de interação, mas também aumenta a segurança, eliminando a necessidade de portas abertas.

Para sistemas de gerenciamento de banco de dados (DBMS) ou outros serviços internos em servidores separados, certifique-se de que o acesso seja restrito a endereços IP específicos que você controla estritamente. Esta configuração evita o acesso não autorizado a sistemas críticos, adiciona uma camada extra de segurança e minimiza os riscos de ataques externos e vazamentos de dados.

5. Você atualiza dependências e software do projeto?

Este conselho é bastante direto, mas, mais uma vez, muitas vezes esquecido: atualize regularmente as dependências e o software do servidor do seu projeto. Código desatualizado e vulnerável é um sonho para invasores que podem explorá-lo facilmente.

Solução: automatize suas atualizações

Você não precisa atualizar tudo manualmente; muitas ferramentas de automação podem ajudar. Por exemplo, Dependebot no GitHub detecta automaticamente dependências desatualizadas ou vulneráveis e sugere atualizações.

Automatizar a renovação de certificados de segurança também é crucial. Se você usar Vamos criptografar certificados, você pode automatizar sua renovação com Certbot . Certificados expirados podem causar muitos problemas, mas automatizar sua renovação é uma tarefa simples.

\O mesmo princípio se aplica ao software de servidor. Se você estiver trabalhando com Linux, especialmente distribuições baseadas em Debian/Ubuntu, Atualizações autônomas pode facilmente lidar com a tarefa. Para projetos maiores com muitos servidores, ferramentas como Ansible , Chefe de cozinha , Fantoche , ou Sal Estão disponíveis.

Pensamentos finais

As dicas fornecidas aqui são apenas uma fração do que os desenvolvedores de back-end precisam lembrar. Optei por destacar tópicos cruciais, mas discutidos com menos frequência em comparação com tópicos comuns, como injeção SQL ou CSRF ataques.

Para uma compreensão mais profunda da segurança de aplicações web, considere explorar o Fundação OWASP , uma organização sem fins lucrativos que oferece recursos valiosos. O Os dez melhores da OWASP documento, disponível em seu site, lista os riscos de segurança de aplicações web mais comuns e críticos. Você também encontrará informações sobre ataques menos conhecidos, mas igualmente perigosos.

Acredito que a comunidade de desenvolvedores deve ter conhecimento e apoiar o compartilhamento de insights e experiências. Portanto, convido a todos a compartilharem suas observações e comentários, que são valiosos para todos que trabalham no desenvolvimento backend!