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

Tome medidas em desenvolvimento para fortalecer e manter o back-end da web seguro.


Pequenas empresas, bancos e muitos setores dependem de aplicativos da web. Desde o momento da criação de um aplicativo da Web, é crucial 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 mais perigosos da Web são aqueles que ocorrem no lado do servidor, onde os dados são armazenados e analisados.

O que é Backend?

Um aplicativo da web é dividido em duas partes – Frontend e Backend.

  • O front-end é do lado do cliente, é a parte com a qual o usuário interage. Normalmente, ele é construído com HTML, CSS e Javascript.
  • O back-end é do lado do servidor. É basicamente como o aplicativo funciona, aplica a lógica de negócios, alterações e atualizações. Algumas das pilhas tecnológicas populares 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 & gerenciamento de sessões

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

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

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

Falhas de injeção

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

As falhas de injeção permitem que o usuário forneça dados contendo palavras-chave que modificarão o comportamento das consultas criadas no banco de dados. Por exemplo, suponhamos que tenhamos um script SQL que verifique se existe uma entrada correspondente no banco de dados.

uname = request.POST [‘nome de usuário’]
passwd = request.POST [‘senha’]
sql = "SELECT id FROM users WHERE nome de usuário = ‘" + uname + "’AND password =’" + passwd + "”"
database.execute (sql)

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

sql = "SELECT id FROM users WHERE nome de usuário = ” AND password = ‘password’ OU 1 = ‘1’

Ao fazer isso, o invasor 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, poderão fazer as alterações que ele desejar.

Como evitá-lo?

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

A melhor e mais 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 através 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 mais nada armazenado, exceto datas.
  • Isole seus dados para que apenas as coisas que devem ser acessadas de um determinado local permaneçam nesse local.
  • Escreva bons códigos de erro de manuseio. Não torne seu banco de dados ou back-end muito detalhado.

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

Autenticação quebrada

Como mencionado anteriormente, a autenticação lida com o fornecimento de credenciais. É a linha de frente da defesa contra acesso irrestrito. No entanto, a má implementação e a falta de respeito à política de segurança podem levar à autenticação quebrada.

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

  • Recheios de credenciais: onde o invasor possui uma lista de nomes de usuário e senhas válidos e pode automatizar o ataque para descobrir que as credenciais são válidas.
  • Ataque Bruteforce: onde o aplicativo permite senhas fracas para usuários ou administradores.
  • Seqüestro de sessão: onde o aplicativo expõe o ID da sessão, 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 dos negócios que podem causar lavagem de dinheiro, roubo de identidade ou divulgar informações altamente confidenciais e protegidas por lei..

Como evitá-lo?

Antes de implementar o sistema de autenticação, pergunte a si mesmo – o que um invasor pode obter se o sistema de autenticação estiver comprometido?

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

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

Controle de acesso quebrado

Existe controle de acesso para garantir o que o usuário autenticado tem permissão para fazer. A autenticação e o gerenciamento de sessões são a base ou as regras 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 direcionar o acesso a métodos.
  • Navegação forçada: o invasor tentará uma URL, modificará os caminhos (por exemplo, http: //wsite.domain/user/ para http: //wsite.domain/admin) e poderá descobrir arquivos importantes.

Como evitá-lo?

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

  • Negar por padrão, exceto recursos públicos.
  • Desative a listagem de diretórios do servidor e verifique se os arquivos de backup não estão presentes.
  • Acesso à API com limite de taxa para reduzir o impacto de ataques automatizados.
  • Invalidar tokens JWT após o logout no lado de back-end.

Exposição de dados

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

Ocorre quando o aplicativo não protege adequadamente informações como credenciais ou dados confidenciais, como cartões de crédito ou registros de saúde. Mais de 4000 registros são violado 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 IBM.

Como evitá-lo?

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:

  • Criptografar dados confidenciais: para dados no 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 monte de usuários legítimos, aplicando a criptografia baseada em chave.
  • Evite um algoritmo de criptografia fraco: use atualizações atualizadas e algoritmos 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 na conversão de dados no formato de objeto, como XML ou JSON, para torná-los utilizáveis. 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 possam ser modificadas para alterar o comportamento.

O segundo exemplo do documento top 10 da 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:"do utilizador";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

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";}

Como evitá-lo?

É 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 seu aplicativo, exceto por uma sequência, verifique se é uma sequência antes de usá-la
  • Use uma verificação para garantir que os dados não foram alterados. É útil você enviar dados entre duas fontes confiáveis ​​(por exemplo, armazenar dados no lado do cliente).

Servidor XSS

Servidor XSS (Script entre sites) é um tipo de injeção quando um invasor usa um aplicativo da Web para enviar código malicioso a diferentes usuários. Ocorre quando o invasor publica alguns dados criados que contêm código malicioso que o aplicativo armazena. Essa vulnerabilidade é do lado do servidor; o navegador simplesmente renderiza a resposta.

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

Como evitá-lo?

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

  • Validar entrada: verifique o comprimento da entrada, use a correspondência de regex e permita apenas um determinado conjunto de caracteres.
  • Validar saída: se o aplicativo copiar em suas respostas a qualquer item de dados originado de algum usuário ou de um terceiro, esses dados deverão 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 apenas o uso de determinadas tags. Se puder, use uma estrutura adequada para a marcação HTML fornecida pelo usuário para tentar garantir que ela não contenha nenhum meio de executar JavaScript.

Conclusão

A fase de desenvolvimento é crucial para a segurança de aplicativos da web. Além disso, considere incluir um scanner de vulnerabilidades de segurança no ciclo de vida do desenvolvimento, para que os problemas identificados sejam corrigidos antes da produção.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map