Este documento é uma visão geral sobre as funcionalidades de segurança do Django. Ele inclui dicas de segurança para sites desenvolvidos em Django.
\nAtaques XSS permitem a um usuário injetar scripts do lado cliente dentro do browser de outros usuários. Isso geralmente é feito armazenando scripts maliciosos no banco de dados onde ele será obtido e exibido para outros usuários, ou fazendo usuários clicarem em um link que faz com que o JavaScript do invasor seja executado pelo browser do usuário. Entretanto, ataques XSS podem se originar de qualquer fonte de dados não confiável, tais como cookies ou serviços Web, sempre que os dados não são suficientemente limpos antes da inclusão em uma página.
\nUsar templates Django protege contra a maioria dos ataques XSS. Porém, é importante entender quais proteções ele fornece e quais são suas limitações.
\nOs templates Django possuem escape de caracteres específicos que são particularmente perigosos para o HTML. Embora isso proteja os usuários da maioria das entradas de dados maliciosas, não é inteiramente a prova de tolos. Por exemplo, ele não protegerá do seguinte:
\n<style class={{ var }}>...</style>\nSe var é definida como 'class1 onmouseover=javascript:func()', isso pode resultar em uma execução não autorizada de JavaScript, dependendo de como o browser renderiza HTML imperfeito. (Adicionar aspas no valor do atributo evitaria isso.)
Também é importante ser especialmente cuidadoso ao usar is_safe com tags de template customizadas, com a tag de template safe, mark_safe, e quando o autoescape está desativado.
Além disso, se você está usando o sistema de template para gerar saídas para algo diferente de HTML, podem existir caracteres inteiramente separados e palavras que necessitaram de escaping.
\nVocê também deve ser muito cuidadoso ao armazenar HTML em um banco de dados, especialmente quando esse HTML é recuperado e exibido.
\nAtaques de solicitações forjadas entre sites, na sigla em inglês, CSRF, permitem que um usuário malicioso execute ações usando as credenciais de outro usuário sem o seu consentimento ou conhecimento.
\nO Django já possui proteção embutida contra a maioria dos tipos de ataques CSRF, contanto que você a tenha habilitado e usado onde apropriado. Porém, assim como em qualquer outra técnica de mitigação, existem limitações. Por exemplo, é possível desabilitar o módulo CSRF globalmente ou para views em particular. Você só deve fazer isso se você souber o que você está fazendo. Existem outras limitações se o seu site tiver subdomínios que estão fora do seu controle.
\nCSRF protection works by checking for a secret in each\nPOST request. This ensures that a malicious user cannot “replay” a form POST to\nyour website and have another logged in user unwittingly submit that form. The\nmalicious user would have to know the secret, which is user specific (using a\ncookie).
\nQuando implantado com HTTPS, CsrfViewMiddleware irá verificar se o referido cabeçalho HTTP está configurado para uma URL na mesma origem (incluindo subdomínio e porta). Como o HTTPS fornece segurança adicional, é imperativo garantir que as conexões utilizem HTTPS quando disponível redirecionando requisições de conexões inseguras e usando HSTS nos browsers suportados.
Tenha cuidado ao marcar views com o decorator csrf_exempt a não ser que isso seja absolutamente necessário.
SQL injection é um tipo de ataque onde o usuário malicioso consegue executar código SQL arbitrário em um banco de dados. Isso pode resultar em registros sendo deletados ou vazamento de dados.
\nDjango’s querysets are protected from SQL injection since their queries are\nconstructed using query parameterization. A query’s SQL code is defined\nseparately from the query’s parameters. Since parameters may be user-provided\nand therefore unsafe, they are escaped by the underlying database driver.
\nDjango also gives developers power to write raw queries or execute custom sql.\nThese capabilities should be used sparingly and you should always be careful to\nproperly escape any parameters that the user can control. In addition, you\nshould exercise caution when using extra()\nand RawSQL.
Clickjacking, ou roubo de click, é um tipo de ataque onde um site malicioso embrulha outro site dentro de um frame. Esse ataque pode resultar em um usuário desavisado sendo levado a fazer ações não intencionadas no site alvo.
\nO Django possui proteção contra clickjacking no form do middleware X-Frame-Options middleware que em um browser com suporte pode prevenir um site de ser renderizado dentro de um frame. É possível desabilitar a proteção por view ou configurar o valor exato a ser enviado no cabeçalho.
O middleware é fortemente recomendado para qualquer site que não precise ter suas páginas envolvidas em um frame por sites de terceiros, ou que só precise permitir isso para uma pequena seção do site.
\nÉ sempre melhor para segurança implantar o seu site usando HTTPS. Sem isso, é possível para redes de usuários mal intencionados farejar credenciais de autenticação ou qualquer outra informação transferida entre o cliente e o servidor, e em alguns casos – invasores ativos na rede – alterarem dados que foram enviados em qualquer direção.
\nSe você quiser a proteção que o HTTPS provê, e o habilitou no seu servidor, existem mais alguns passos adicionais que você pode precisar:
\nSe necessário, ativar SECURE_PROXY_SSL_HEADER, certificando-se que você entendeu completamente os avisos mencionados lá. Falhar ao fazer isso pode resultar em vulnerabilidades de CSRF, e falhar em fazer isso corretamente podem ainda ser perigoso!
Ativar SECURE_SSL_REDIRECT configurando para True, de modo que as requisições via HTTP sejam redirecionadas para HTTPS.
Por favor, preste atenção nos avisos em SECURE_PROXY_SSL_HEADER. Para o caso de um proxy reverso, pode ser mais fácil ou mais seguro configurar o principal Web server para fazer o redirecionamento para HTTPS.
Utilize cookies ‘seguros’.
\nSe um browser conecta inicialmente via HTTP, o que é o padrão na maioria dos browsers, é possível que cookies existentes sejam vazados. Por essa razão, você deve ativar os settings SESSION_COOKIE_SECURE e CSRF_COOKIE_SECURE para True. Isso instrui o browser a só enviar os cookies em conexões sobre HTTPS. Repare que isso significa que as sessões não irão funcionar sobre HTTP (o que não é um problema se você está redirecionando todo o seu tráfego HTTP para HTTPS).
Utilize HTTP Strict Transport Security (HSTS)
\nHSTS is an HTTP header that informs a browser that all future connections\nto a particular site should always use HTTPS. Combined with redirecting\nrequests over HTTP to HTTPS, this will ensure that connections always enjoy\nthe added security of SSL provided one successful connection has occurred.\nHSTS may either be configured with SECURE_HSTS_SECONDS,\nSECURE_HSTS_INCLUDE_SUBDOMAINS, and SECURE_HSTS_PRELOAD,\nor on the Web server.
O Django usa o cabeçalho Host fornecido pelo cliente para construir URLs em alguns casos. Embora esses valores sejam tratados para prevenir ataques de Cross Site Scripting, um valor Host falso pode ser usado para ataques como Cross-Site Request Forgery, envenenamento de cache, e envenenamento de links em emails.
Como até mesmo configurações de web server aparentemente seguras estão sujeitas a cabeçalhos Host falsos, O Django valida o cabeçalho Host comparando com o setting ALLOWED_HOSTS dentro do método django.http.HttpRequest.get_host().
Essa validação só é aplicada através do método get_host(); se o seu código acessa o cabeçalho Host diretamente do request.META você está contornando essa proteção de segurança.
Para mais detalhes veja a documentação completa do setting ALLOWED_HOSTS.
Adicionalmente, o Django requer que você ative explicitamente o suporte para o cabeçalho X-Forwarded-Host (através do setting USE_X_FORWARDED_HOST) se a sua configuração exigir ele.
Browsers use the Referer header as a way to send information to a site\nabout how users got there. By setting a Referrer Policy you can help to\nprotect the privacy of your users, restricting under which circumstances the\nReferer header is set. See the referrer policy section of the\nsecurity middleware reference for details.
De forma similiar as :ref:` limitações CSRF <csrf-limitations>` requerendo que o deploy de um site seja feito de modo que usuários não tenham acesso a quaisquer subdomínios, o módulo django.contrib.sessions também tem limitações. Veja a seção de segurança do guia que fala sobre sessions para mais detalhes.
Se o seu site aceita uploads de arquivos, é fortemente aconselhável que você limite esses uploads nas configurações do seu servidor Web para um tamanho apropriado e assim possa prevenir ataques do tipo denial of service (DOS). No Apache, isso pode ser facilmente configurado usando a diretiva LimitRequestBody .
Se você estiver fornecendo os seus próprios arquivos estáticos, certifique-se de que handlers como o mod_php, que são capazes de executar arquivos estáticos como código, estejam desabilitados. Você não quer que usuários sejam capazes de executar código arbitrário através do upload e solicitação de um arquivo especialmente criado.
A manipulação de envio de mídia no Django expõe algumas vulnerabilidades quando esta mídia é servida de maneiras que não seguem as melhores práticas de segurança. Especificamente, um arquivo HTML pode ser enviado como imagem se o arquivo contiver um cabeçalho PNG válido seguido por um HTML malicioso. Este arquivo irá passar a validação da biblioteca ImageField que o Django usa para processar imagem (Pillow). Quando este arquivo é subsequentemente mostrado para um usuário, ele pode ser mostrado como HTML dependendo do tipo de configuração do seu servidor web.
Não existe solução à prova de balas a nível de framework para validar com segurança todos os uploads de arquivos de usuários, entretanto, existem mais alguns passos que você pode dar para mitigar esses ataques:
\nUma classe de ataques pode ser prevenida servindo sempre conteúdo proveniente de uploads de um domínio de primeiro nível ou de um domínio de segundo nível. Isso previne qualquer vulnerabilidade bloqueada por proteções do tipo same-origin policy tais como CSS. Por exemplo, se o seu site está hospedado em example.com, você vai querer fornecer conteúdo proveniente de uploads (o setting MEDIA_URL) de algo como usercontent-example.com. Não basta apenas fornecer conteúdo de um subdomínio como usercontent.example.com.
Beyond this, applications may choose to define a list of allowable\nfile extensions for user uploaded files and configure the web server\nto only serve such files.
Embora o Django forneça uma boa proteção de segurança já de início, ainda é importante fazer corretamente o “deploy”, ou seja, fazer adequadamente a implantação do seu sistema tirando proveito da proteção de segurança do servidor Web, do sistema operacional e de outros componentes.
\nCertifique-se de que o seu código Python está fora do diretório raiz do seu servidor Web. Isso garantirá que o seu código Python não seja acidentalmente fornecido em texto puro (ou acidentalmente executado).
Tome cuidado com qualquer arquivo originado de uploads de usuários.
O Django não impõe um limite nas requisições para autenticação de usuários. Para se proteger contra ataques de força-bruta contra sistemas de autenticação, você pode decidir adicionar ao seu deploy um plugin Django ou um módulo no servidor Web que limite essas requisições.
Mantenha a sua SECRET_KEY um segredo.
É uma boa idéia limitar a acessibilidade de seu sistema de cache e banco de dados, utilizando um firewall.
Dê uma olhada no `Top 10 `_ do “Projeto Aberto de Segurança de Aplicações Web”, em inglês Open Web Application Security Project (OWASP), que identifica algumas vulnerabilidades comuns em aplicações web. Embora o Django tenha ferramentas para solucionar alguns desses problemas, outros problemas devem ser resolvidos no design do seu projeto.
Mozilla discusses various topics regarding web security. Their\npages also include security principles that apply to any system.