O REST é uma arquitetura de aplicativo da web extremamente popular. Para chamar funções no servidor, solicitações HTTP comuns com parâmetros especificados são usadas (JSON ou XML geralmente é usado para estruturar parâmetros), enquanto não há um padrão estrito para a arquitetura REST, que adiciona flexibilidade (e, é claro, um pouco de caos).
O REST permite abordar de maneira flexível a questão da segurança ou, do que muitos pecam, não abordar a questão. Com base no
OWASP , preparamos uma lista de dicas para ajudá-lo a melhorar a segurança do seu aplicativo REST.
Como ponto de partida nesses casos raros em que é necessário aqui, usamos python e Django.
Regra 0
Https
Basta configurá-lo. Por favor A proteção dos dados transmitidos não prejudicou ninguém. Mesmo que você ache que não há nada a proteger no momento, isso nem sempre será o caso e você ainda precisará configurar o HTTPS. Portanto, configure-o melhor imediatamente e todos ficarão bem.
Regra 1
Autenticação
Parece conselho óbvio, que, no entanto, muitos preferem negligenciar. O aplicativo sempre deve ter autenticação, mesmo que agora você pense que o utilizará apenas dentro da empresa e não haja diferença de qual funcionário o faz. E se você complementá-lo com revistas, a investigação de incidentes e a análise de atividades se tornarão incomparavelmente mais simples.
Como tokens de acesso, atualmente é considerado uma boa prática usar o
JWT (tokens da web JSON). Não use tokens com o valor {"alg": "none"} para controle de integridade; os tokens devem sempre conter uma assinatura ou MAC! Uma assinatura é preferível devido ao fato de que as chaves de geração e verificação do MAC correspondem (ou podem ser facilmente calculadas uma da outra), ou seja, se o servidor puder verificar o valor do MAC, ele também poderá gerar seus valores. A assinatura também confirma não apenas a integridade da mensagem, mas também a identidade do remetente.
Regra 2
Negue métodos HTTP que você não usa
Configure o servidor para colocar na lista branca os métodos com os quais você trabalha (GET, POST, PUT etc.) e rejeitar qualquer coisa que não se encaixe nessa lista. É improvável que seu servidor precise processar solicitações TRACE na produção (esse método faz parte do ataque XST (Cross-Site Tracing), que consiste em um ataque XSS e o método TRACE ou TRACK. Esse ataque permite, por exemplo, roubar os cookies do usuário, mesmo que eles estão marcados como HttpOnly). Quanto menos informações sobre sua infraestrutura estiverem disponíveis externamente, melhor.
Regra 3
Acesso diferenciado
Todos os seus usuários precisam de todos os métodos, por exemplo, DELETE? Se você não deseja que alguns usuários possam executar determinadas operações - configure o controle de acesso no seu aplicativo. Por exemplo, um usuário comum pode acessar apenas o método GET para algumas funções, o gerente pode usar GET e POST, etc. Para isso, vale a pena definir funções no banco de dados que possam ser atribuídas aos usuários para um controle de acesso conveniente.
Como resultado, cada função terá um bloco de verificação desse tipo aproximadamente:
if request.POST and user.is_manager: do_stuff()
Regra 4
Pense em limitar o número de consultas
Se você acha que seus usuários não devem enviar cem mil solicitações por segundo, limite esse número. Use chaves de API ou qualquer outro mecanismo conveniente para rastrear e limitar o número de solicitações que serão processadas em um determinado período de tempo de um usuário. Para o Django, por exemplo, o django-ratelimit fornece essa funcionalidade, na qual você pode definir vários parâmetros como um identificador para a restrição, não necessariamente chaves da API, mas um endereço IP.
Regra 5
Certifique-se de validar / higienizar a entrada
Nunca confie nos parâmetros de entrada transmitidos, sempre realize validação / saneamento:
- Se possível (e sempre que possível), defina um limite para o comprimento / tipo / formato da entrada e a própria solicitação. Rejeite todas as solicitações / dados transmitidos que excedam o comprimento especificado por você ou que não correspondem ao tipo / formato.
- Ao processar seqüências de caracteres, sempre escape todos os caracteres especiais.
- Se você usa a estrutura, a maioria contém suas próprias ferramentas internas de validação e saneamento (prontamente usadas pelas populares - Django (python) e Yii2 (php)), por isso é importante estudar suas capacidades e se algum aspecto necessário não for coberto - encontre uma biblioteca que feche isso ou escreva você mesmo essa funcionalidade.
- Acompanhe os erros de validação. Se as solicitações de alguns usuários falharem constantemente na validação - pense em bloquear automaticamente esses usuários.
- Verifique se o analisador de entrada (ou a versão atual) não é suscetível a ataques por si só.
Regra 6
Não forneça mais informações do que o necessário
Se alguma solicitação causou um erro no aplicativo ou simplesmente não está disponível por algum motivo, não forneça detalhes na resposta, retorne a mensagem de erro mais abstrata. Alguns servidores retornam o rastreamento de pilha após um erro por padrão, portanto, reconfigure essa lógica.
Regra 7
Sempre mantenha registros
Permita que cada evento (autenticação, erro, solicitação, etc.) seja registrado o mais detalhado possível. Registre-os logicamente para uma pesquisa mais conveniente, se necessário. Por precaução, antes de gravar nos logs, desinfete os dados gravados.
Regra 8
Indique o tipo de conteúdo corretamente - isso é importante!
Para que o navegador (ou cliente) leia corretamente os dados fornecidos, o Tipo de Conteúdo especificado corretamente correspondente aos dados fornecidos é importante. No caso de navegadores, também vale a pena definir o cabeçalho X-Content-Type-Options: nosniff, para impedir que o navegador tente detectar outro tipo de conteúdo além daquele que foi realmente enviado (uma medida contra ataques XSS).
Regra 9
Validar tipo de conteúdo
- Vale a pena configurar a rejeição de solicitações se o tipo de conteúdo diferir do conteúdo. Isso reduzirá o risco de processamento de dados incorreto, o que pode levar à injeção ou execução de código no servidor / cliente.
- Também vale a pena rejeitar solicitações cujo tipo de conteúdo você não oferece suporte ou para o qual esse cabeçalho geralmente está ausente. Além disso, evite respostas diretas sobre qual função do tipo de conteúdo aceita / problemas, se isso não for necessário (isso ajudará a evitar ataques XXE).
- Nos serviços REST, é comum oferecer suporte a vários tipos de respostas (por exemplo, json e xml), e o cliente indica o tipo de resposta preferido no cabeçalho Accept ao solicitar. Evite copiar o conteúdo do cabeçalho Accept no tipo de conteúdo da resposta como um mecanismo para definir esse cabeçalho. Rejeite também solicitações para as quais o cabeçalho Accept não contenha diretamente pelo menos um dos tipos suportados.
Regra 10
Não se esqueça de configurar o CORS (compartilhamento de recursos entre origens)
O CORS é um padrão que descreve o trabalho com consultas entre domínios. Se o seu aplicativo não suportar CORS, desative o trabalho com esse tipo de cabeçalho. Se você precisar usá-lo, a política de acesso deve ser o mais específica e rigorosa possível.
Regra 11
Não expanda parâmetros no URL
Todos os dados críticos (senhas, chaves, tokens e logins, de preferência também) devem estar dentro do corpo da solicitação ou nos cabeçalhos, mas em nenhum caso devem aparecer no URL. Se você precisar passar dados confidenciais pelo método GET, coloque-os no cabeçalho.
É impossível:exemplo .com / controller / 123 / action? apiKey = a53f435643de32
Você pode:exemplo .com / controller / 123 / action
Cabeçalhos:Anfitrião: example.com
Agente do Usuário: Mozilla ...
Chave X-API: a53f435643de32
Regra 12
Pense na proteção contra ataques CSRF
Você pode ler mais sobre todos os tipos de proteção
aqui e, portanto, o uso de tokens de CSRF é considerado a maneira mais popular de reduzir o risco de ataques desse tipo.
Regra 13
Explore sua estrutura
Se você usa qualquer estrutura para implementar o REST em seu aplicativo, deve estudá-lo e não usá-lo cegamente, como costuma ser feito. Leia a documentação com atenção, especialmente a parte de segurança. Não o deixe funcionando nas configurações padrão! Cada estrutura possui suas próprias nuances, especialmente quando se trata de segurança, portanto, conhecê-las é muito importante.