Dicas de segurança para Django

Que sorte a sua usar o framework web para perfeccionistas com prazos (também conhecido como Django)! A equipe do Django refletiu bastante sobre práticas de segurança (confira os recursos de segurança na documentação; a política de segurança também é interessante). Reunimos algumas das melhores dicas para manter seu projeto Django seguro.

Baixe nosso guia rápido com dicas de segurança para Django.

Saiba qual versão você usa e escolha uma versão segura

Qual versão do Django você usa? Atualmente, há três versões principais do Django em uso (embora o suporte de longo prazo à versão 1.11 termine em abril de 2020). A versão do Django que você usa tem várias implicações para o seu projeto. Por exemplo, a versão 1.11 é a última a usar Python 2, cujo suporte foi encerrado no início de 2020.

Além disso, a escolha da versão determina quais vulnerabilidades conhecidas estão presentes e podem ser exploradas na sua aplicação. Saiba mais sobre vulnerabilidades conhecidas do Django no nosso banco de dados de vulnerabilidades ou analise seu projeto com o Snyk. Vamos avisar se você estiver usando uma versão vulnerável.

Por fim, é importante ter um plano para manter sua versão do Django atualizada. Em geral, é uma boa ideia escolher uma versão com suporte de longo prazo e planejar a migração para a próxima antes que o suporte à versão atual termine. Assim, você conta com o suporte dos mantenedores sem precisar trocar de versão o tempo todo.

Uma observação: consulte a documentação da versão correta do Django. Você não vai querer acreditar que uma política de segurança está em vigor por ter lido sobre ela na documentação e só depois descobrir que a versão que usa não corresponde à versão documentada.

Limite as tentativas de autenticação

O Django já vem com muitos recursos de segurança, mas o sistema de autenticação não protege, por si só, contra ataques de força bruta. Um agente mal-intencionado pode fazer inúmeras tentativas de login no seu sistema e, potencialmente, conseguir acesso.

Se esse tipo de ataque preocupa você, use um projeto como o Django Defender para bloquear usuários após muitas tentativas de login.

Proteja seu código-fonte

Proteger seu código-fonte pode parecer uma medida óbvia, mas há vários aspectos a considerar. Uma forma de protegê-lo é garantir que ele não esteja no diretório raiz do seu servidor web. Caso esteja, ele pode ser disponibilizado ou executado parcialmente de uma maneira que você não planejou.

E, embora seja óbvio, se o seu projeto contiver informações sensíveis, use um repositório privado no GitHub, Bitbucket ou GitLab. Além disso, nunca armazene seus segredos no sistema de controle de versão, mesmo que pretenda usar um repositório privado. Um repositório privado pode deixar de ser privado, e nem sempre é possível confiar em todos que têm acesso a ele.

Use consultas brutas e SQL personalizado com cuidado

Embora seja tentador escrever consultas SQL brutas e SQL personalizado, isso pode abrir brechas para ataques. O framework de mapeamento objeto-relacional (ORM) do Django foi criado para facilitar as consultas ao banco de dados. Os QuerySets são montados com parametrização de consultas, que separa os parâmetros do código SQL da consulta. Se você sempre usar o ORM, será muito mais difícil para alguém realizar uma injeção de SQL (executar SQL arbitrário em um banco de dados).

O Django permite o uso de consultas brutas, mas não recomenda essa prática. Se você optar por usá-las, tome cuidado redobrado para escapar corretamente todos os parâmetros. Se o ORM do Django não atender às suas necessidades, é possível usar outro ORM no Django. O SQLAlchemy, por exemplo, é compatível com o Django. Se outro ORM atender melhor às necessidades do seu projeto, prefira usá-lo a escrever muito SQL bruto.

Use HTTPS

Independentemente do framework escolhido, o ideal é sempre fazer a implantação usando HTTPS. Isso impede que usuários mal-intencionados interceptem as informações enviadas entre o cliente e o servidor. Para que o HTTPS funcione corretamente, é importante configurar tudo da maneira adequada.

As configurações a seguir são importantes para o uso do HTTPS. Entenda cada uma delas e habilite-as corretamente. A documentação explica bem as configurações, os padrões seguros e por que talvez seja necessário alterá-las em determinadas situações.

• SECURE_PROXY_SSL_HEADER

• SECURE_SSL_REDIRECT

• SESSION_COOKIE_SECURE

• CSRF_COOKIE_SECURE

• SECURE_HSTS_SECONDS

• SECURE_HSTS_INCLUDE_SUBDOMAINS

• SECURE_HSTS_PRELOAD

Fique de olho nos cabeçalhos

Primeiro, vamos analisar especificamente o cabeçalho de requisição referer. Ele contém o endereço da página web anterior, de onde você veio para chegar à página atual. Essas informações são úteis para análises, entre outras coisas. Às vezes, porém, elas causam problemas, pois, em geral, as pessoas não gostam de ser rastreadas pela web. Por questões de privacidade, é possível desativar essa funcionalidade. O cabeçalho referer-policy determina se o cabeçalho referer é enviado e quais informações são compartilhadas: em algumas condições, apenas parte delas é transmitida; em outras, todas as informações são incluídas; e, às vezes, nada é encaminhado.

Quando o site é servido por HTTPS, o Django usa o cabeçalho de requisição referer para ajudar a prevenir ataques de falsificação de solicitação entre sites (CSRF). Se a política do cabeçalho referer-policy for restritiva demais, você desativa essa proteção do Django contra CSRF. No fim, é preciso ponderar os benefícios de privacidade de uma política referer-policy rigorosa e os benefícios da proteção contra CSRF. É possível encontrar um meio-termo permitindo apenas referenciadores da mesma origem no cabeçalho referer-policy.

Tenha cuidado com os cookies

Alguns cookies são mais seguros que outros: por padrão, eles são enviados por HTTP. Mas, como já vimos, você precisa usar HTTPS e garantir que os cookies também sejam enviados somente por HTTPS. Para evitar o vazamento de cookies, defina as configurações SESSION_COOKIE_SECURE e CSRF_COOKIE_SECURE como True. Isso instrui o navegador a enviar esses cookies apenas em conexões HTTPS. Definir esses parâmetros como True pode ter alguns efeitos colaterais, mas é possível reduzi-los redirecionando o tráfego HTTP para HTTPS.

Trate os uploads de usuários com cuidado

Se a sua aplicação web permite que usuários enviem arquivos, você abre uma possível via de ataque. Por isso, a lógica de upload deve ser tratada com cuidado. Primeiro, é importante validar todos os arquivos enviados para garantir que sejam o que você espera (por exemplo, uma imagem, e não um script PHP!). Você não quer permitir que alguém execute código.

Há várias medidas para validar os arquivos enviados e tratá-los com mais cuidado. Veja algumas:

• Crie uma lista de permissões com os tipos de arquivo aceitos

• Limite o tamanho dos arquivos enviados para evitar problemas de negação de serviço

• Desative handlers que executem arquivos estáticos como código (por exemplo, desative o mod_php do Apache)

• Use as proteções contra cross-site scripting a seu favor. Se você servir o conteúdo dos usuários em um domínio de nível superior separado, as proteções contra cross-site scripting serão acionadas para proteger você. Esse domínio pode ser seu, embora provavelmente seja mais fácil servir os arquivos por meio de um serviço de nuvem ou de um provedor de rede de distribuição de conteúdo.

Entenda todas as suas dependências

Se você escolheu uma versão do Django com poucos ou nenhum risco de segurança conhecido, talvez pense que não há mais problemas de segurança a considerar. No entanto, é importante entender quais bibliotecas de código aberto o Django importa e se elas têm vulnerabilidades.

Quando você inclui o Django (ou qualquer biblioteca de código aberto), normalmente também inclui todas as bibliotecas usadas pela biblioteca escolhida. O código aberto é construído sobre código aberto, que por sua vez se apoia em ainda mais código aberto.

Dependências indiretas podem trazer tantos riscos quanto as diretas, mas esses riscos são menos reconhecidos. Uma ferramenta como o Snyk ajuda você a entender toda a árvore de dependências. E agora que o Snyk oferece pull requests com correções para Python, resolver problemas (inclusive em dependências indiretas) está mais fácil do que nunca.

Não deixe que o perfeito seja inimigo do bom

Cada medida de segurança que você adota é um passo na direção certa. O Django pode ser feito para perfeccionistas com prazos, mas seu código não precisa ser perfeito para se beneficiar de melhorias de segurança. Aplicar os conceitos acima da melhor forma possível pode aumentar muito a segurança do seu código e tornar seu projeto mais saudável e resiliente. Bom código, Pythonistas!