6 Riscos de segurança de back-end da Web a serem considerados no desenvolvimento

Netsparker Web Application Security Scanner - a única solução que oferece verificação automática de vulnerabilidades com Proof-Based Scanning ™.

Por Onael Mangaboem 20 de janeiro de 2020Postado em

• Desenvolvimento
• Segurança

Tome medidas no desenvolvimento para proteger e manter o back-end da web seguro.

Pequenas empresas, bancos e muitos setores dependem de aplicativos da web. Desde o momento da construção de um aplicativo da web, é crucial ter certeza de ter protocolos para verificar vulnerabilidades à medida que o desenvolvimento evolui para evitar violações de segurança, vazamentos de dados e problemas financeiros.

Os ataques da Web mais perigosos são aqueles que ocorrem no lado do servidor, onde os dados são armazenados e analisados.

O que é back-end?

Um aplicativo da web é dividido em duas partes - front-end e back-end.

• O frontend está do lado do cliente, é a parte com a qual o usuário interage. Normalmente, é construído com HTML, CSS e Javascript.
• O back-end está do lado do servidor. É basicamente como o aplicativo funciona, aplica a lógica de negócios, alterações e atualizações. Algumas das pilhas de tecnologia populares do lado do servidor envolvem PHP, NodeJS, Java, Ruby, C, Python, banco de dados, segurança (autenticação, controle de acesso, etc.), estrutura e gerenciamento de conteúdo.

Um pequeno lembrete antes de começarmos - autenticação, controle de acesso e gerenciamento de sessão

É comum confundirmos os termos. Então, vamos esclarecer isso rapidamente:

• A autenticação envolve a comprovação da identidade do usuário (por exemplo, senha, nome de usuário, questões de segurança, impressões digitais)
• O controle de acesso diz respeito ao que o usuário pode acessar o aplicativo. Ele impõe a política de que os usuários não podem agir fora de suas permissões pretendidas.
• O gerenciamento de sessão diz respeito a respostas e transações de solicitação associadas ao mesmo usuário. É um mecanismo de troca que é usado entre o usuário e o aplicativo depois que ele se autentica com sucesso.

Vamos explorar o seguinte para melhor segurança back-end da web.

Falhas de injeção

Desde 2010, o OSWAP classificou a injeção como o risco número 1 de aplicativos da Web mais perigosos.

As falhas de injeção permitem que um usuário forneça dados contendo palavras-chave que modificarão o comportamento das consultas construídas no banco de dados. Por exemplo, vamos supor que temos um script SQL que verifica se existe uma entrada correspondente no banco de dados.

uname = request.POST['username']
passwd = request.POST['password']
sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"
database.execute(sql)cópia de

Um invasor agora pode manipular o campo de senha usando injeção de SQL , por exemplo, digitando a senha 'OR 1 =' 1, que leva à seguinte consulta SQL:

sql = "SELECT id FROM users WHERE username='' AND password='password' OR 1='1'

Desta forma, o atacante pode acessar todas as tabelas de usuários do banco de dados, sendo a senha sempre válida (1 = '1'). Se eles fizerem login como administrador, eles podem fazer as alterações desejadas.

Como prevenir?

É muito FÁCIL evitar falhas de injeção.

A melhor e simples maneira de verificar se não há falhas de injeção é uma revisão manual completa do código-fonte para verificar se as consultas no banco de dados são feitas por meio de instruções preparadas. Você também pode usar ferramentas para verificar vulnerabilidades .

E você também deve fazer o seguinte.

• Use ORMs (Object Relational Mapping Tools).
• Escape de todas as entradas. Um campo de data nunca deve ter nada mais armazenado neles, exceto datas.
• Isole seus dados de forma que apenas o que deve ser acessado de um determinado local seja mantido naquele local.
• Escreva códigos de erro de bom manuseio. Não torne seu banco de dados ou seu back-end muito prolixo.

Troy Hunt obteve um curso brilhante sobre injeção de SQL. Se estiver interessado, você pode explorar isso.

Autenticação quebrada

Conforme mencionado anteriormente, a autenticação lida com o fornecimento de credenciais. É a linha de frente da defesa contra o acesso irrestrito. No entanto, a implementação deficiente e o não respeito da política de segurança podem levar à quebra da autenticação.

A autenticação quebrada ocorre principalmente por três padrões:

• Recheio de credenciais: onde o invasor tem uma lista de nomes de usuários e senhas válidos e pode automatizar o ataque para descobrir se as credenciais são válidas.
• Ataque de força bruta: onde o aplicativo permite senhas fracas para usuários ou administradores.
• Sequência de sessão: onde o aplicativo expõe o ID da sessão, URL ou não gira após o login.

Em todos os casos, o invasor pode obter acesso a uma conta importante e depender da empresa que pode causar lavagem de dinheiro, roubo de identidade ou divulgar informações protegidas legalmente e altamente confidenciais.

Como prevenir?

Antes de implementar o sistema de autenticação, pergunte a si mesmo - o que um invasor pode conseguir se o sistema de autenticação for comprometido?

E de acordo com a resposta, você pode fazer o seguinte.

• Implemente a autenticação multifator para evitar ataques automatizados.
• Incentive (ou force) o usuário a adotar uma boa política de senha.
• Limite de logins com falha.
• Use hash de algoritmo eficiente. Ao escolher um algoritmo, considere o comprimento máximo da senha.
• Teste o sistema de tempo limite de sessão e certifique-se de que o token de sessão seja invalidado após o logout.

Controle de acesso quebrado

O controle de acesso existe para garantir o que o usuário autenticado tem permissão para fazer. A autenticação e o gerenciamento de sessão são as regras básicas de controle de acesso. Mas quando essas regras não estão bem definidas, isso pode levar a problemas significativos.

As falhas comuns de controle de acesso incluem:

• Configuração incorreta do CORS que permite acesso não autorizado à API.
• Manipulação de metadados para acesso direto aos métodos.
• Navegação forçada: O invasor tentará uma URL, modificará caminhos (por exemplo, http: //website.domain/user/ para http: //website.domain/admin) e pode até descobrir arquivos importantes.

Como prevenir?

Principalmente, as falhas de acesso interrompidas ocorrem por ignorância sobre os requisitos essenciais de gerenciamento de acesso eficaz.

• Negar por padrão, exceto recursos públicos.
• Desative a lista de diretórios do servidor e certifique-se de que os arquivos de backup não estejam presentes.
• Limite de taxa o acesso à API para reduzir o impacto de ataques automatizados.
• Invalide tokens JWT após o logout no lado do back-end.

Exposição de dados

Também conhecido como violação de dados, a exposição de dados é uma ameaça cibernética que ameaça as empresas e seus clientes.

Isso ocorre quando o aplicativo não protege adequadamente as informações, como credenciais ou dados confidenciais, como cartões de crédito ou registros de saúde. Mais de 4000 registros são violados a cada minuto .

O impacto nos negócios é grande do lado financeiro: uma violação média pode custar US $ 3,92 milhões, de acordo com a IBM .

Como prevenir?

Como desenvolvedor de back-end, você deve perguntar quais são as informações que precisam de proteção.

E então, para evitar tais falhas:

• Criptografe dados confidenciais: para dados em REST, criptografe tudo. Para dados em trânsito, certifique-se de usar gateways seguros ( SSL )
• Identifique os dados que requerem proteção extra e limite a acessibilidade a apenas um grupo de usuários legítimos, aplicando a criptografia baseada em chave.
• Evite algoritmos de criptografia fracos: use algoritmos atualizados e fortes .
• Tenha um plano de backup seguro.

Desserialização insegura

Serialização e desserialização são conceitos usados ​​quando os dados são convertidos em formato de objeto para serem armazenados ou enviados para outro aplicativo. A serialização consiste em converter dados em formato de objeto como XML ou JSON para torná-los utilizáveis. A desserialização é apenas o processo inverso.

Ataques contra desserializadores podem levar a ataques de negação de serviço, controle de acesso e execução remota de código (RCE) se houver classes que podem ser modificadas para alterar o comportamento.

O segundo exemplo do documento dos 10 principais OWASP fornece uma boa ilustração do serializador de objetos PHP:

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}cópia de

Este é um supercookie que contém informações como ID do usuário, o nível do usuário e a senha com hash.

Um invasor pode alterar o objeto serializado para obter acesso aos privilégios de administrador:

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}cópia de

Como prevenir?

É crucial não aceitar objetos serializados de fontes não confiáveis.

Você também deveria:

• Nunca confie na entrada do usuário.
• Validar dados: se o seu aplicativo não for uma string, certifique-se de que seja uma string antes de usá-la
• Use uma verificação para ter certeza de que os dados não foram alterados. É útil que você envie dados entre duas fontes confiáveis ​​(por exemplo, armazenamento de dados do lado do cliente).

Servidor XSS

Servidor XSS (Cross-site scripting) é um tipo de injeção quando um invasor usa um aplicativo da web para enviar código malicioso a diferentes usuários. Isso ocorre quando o invasor publica alguns dados elaborados contendo código malicioso que o aplicativo armazena. Essa vulnerabilidade está no lado do servidor; o navegador simplesmente renderiza a resposta.

Por exemplo, em um fórum, as postagens do usuário são salvas em um banco de dados, geralmente sem verificação. Os invasores aproveitam esta oportunidade para adicionar postagens com scripts maliciosos. Posteriormente, outros usuários recebem este link por e-mail ou veem a postagem em questão e clicam nela.

Como prevenir?

Após a identificação primária de todas as operações que estão potencialmente em risco de XSS e que precisam ser protegidas, você deve considerar o seguinte.

• Validar a entrada: verifique o comprimento da entrada, use a correspondência de regex e permite apenas um determinado conjunto de caracteres.
• Saída de validação: se o aplicativo copiar em suas respostas a qualquer item de dados originado de algum usuário ou terceiro, esses dados devem ser codificados em HTML para limpar caracteres potencialmente maliciosos.
• Permitir limite de HTML: por exemplo, se você tiver um sistema de blog de comentários, permita o uso de apenas algumas tags. Se possível, use uma estrutura adequada para marcação HTML fornecida pelo usuário para tentar ter certeza de que ela não contém nenhum meio de execução de JavaScript.

Conclusão

A fase de desenvolvimento é crucial para a segurança do aplicativo da web. E, você deve considerar a inclusão de um scanner de vulnerabilidades de segurança no ciclo de vida de desenvolvimento, para que os problemas identificados sejam corrigidos antes da produção.