Mergulho Técnico no OWASP

Em termos de segurança, muitas coisas precisam ser tratadas e evitadas, mas algumas precisam de mais atenção. Sem discussão, o melhor guia para esses problemas de segurança é The Open Web Application Security Project.

Apesar de OWASP iniciado como um projeto simples para conscientizar os desenvolvedores e gerentes sobre os problemas mais comuns de segurança na web, hoje em dia se tornou um padrão em segurança de aplicativos.

Neste artigo, apresentaremos uma visão geral técnica mais detalhada de algumas das vulnerabilidades listadas no projeto OWASP e como mitigá-las. Faremos código incorreto – bons exemplos de código lado a lado, para entender e prevenir melhor esses tipos de ataques e melhorar nossa segurança de aplicativos da web.

Injeção

Esse tipo de problema ocorre quando um programa permite que um invasor forneça dados de entrada não confiáveis ​​/ mal-intencionados, fazendo com que o intérprete execute comandos não designados geralmente para revelar dados que de outra forma seriam inacessíveis ou ignorar alguma implementação de segurança.

A causa mais comum de vulnerabilidades de injeção resulta da falha de um software em filtro, validar ou higienizar entrada de um usuário.

Vamos dar uma olhada em duas “implementação de código incorreta” que permitem ataques de injeção.

Exemplo de código incorreto 1:

Digamos que você tenha uma rota de login que receba o email e, por qualquer motivo, receba a senha já com hash.

Se soubermos que o endereço de e-mail de um usuário, por exemplo, [email protected], podemos facilmente ignorar esse sistema de login enviando o seguinte objeto JSON, que cria uma injeção NoSQL.

{        "email": "[email protected]",        "password": { "$ne": "" }}

Este objeto instruirá o MongoDb a encontrar um usuário com o email “[email protected]” e com uma senha diferente de uma sequência vazia.

Este exemplo pode ser um pouco exagerado, mas dê uma olhada no código a seguir e pense por si mesmo se conseguir identificar o problema.

Exemplo de código incorreto 2:

Neste exemplo, temos um formulário de registro na interface com o seguinte código no back-end:

Como podemos explorar esse código? Muito simples, digamos que neste exemplo o esquema do usuário tenha a seguinte aparência.

export const UserSchema = new mongoose.Schema({    email: {        type: String,        required: true,        unique: true    },    password: {        type: String,        required: true    },    admin: {        type: Boolean,        default: false    },    accountConfirmed: {        type: Boolean,        default: false    },}, );

Agora basta enviar a seguinte solicitação POST com o Postman ou qualquer outra ferramenta que você preferir usar.

{    "email": "my-email",    "password": "123321",    "admin": "true",    "accountConfirmed": "true"}

E agora você se registrou com sucesso neste site, mas não como um usuário simples, mas com uma conta de administrador confirmada.

O problema aqui é que, se simplesmente usarmos:

{ ...req.body }

Então criaremos um novo objeto de usuário com todas as propriedades dentro do objeto corpo, então aqui podemos injetar o que quisermos.

Reestruturação

Vamos refatorar o código dos dois exemplos para evitar esse tipo de ataque

Para o primeiro exemplo, podemos verificar o tipo esperado para email e senha. No nosso caso, estamos aguardando uma sequência nos dois campos:

Se fornecermos novamente os mesmos parâmetros:

{	"email": "[email protected]",	"password": { "$ne": "" }}

Nós receberemos um 400 Solicitação incorreta resposta. Podemos ir ainda mais longe e verificar se o email é realmente um email e não apenas uma sequência simples, mas isso está fora do nosso escopo por enquanto.

Para o segundo, podemos usar a validação de entrada do servidor na lista de permissões removendo as propriedades indesejadas

Esses exemplos foram para injeção NoSQL, mas essa técnica pode ser estendida para injeção SQL também.

Usando componentes com vulnerabilidades conhecidas

Anteriormente, vimos alguns padrões de segurança mal implementados, cometidos por nossos erros. No entanto, há situações em que o problema não é do código que escrevemos, mas do código de código aberto que usamos em nosso projeto.

Um invasor explora as vulnerabilidades desses componentes para executar código malicioso ou fazer com que o programa se comporte de maneira indesejada.

Mesmo que isso pareça estar fora do seu alcance, existem medidas que podemos tomar para evitar esse tipo de problema.

Por exemplo, podemos fazer um inventário contínuo para versões de componentes do lado do cliente e do servidor e remover dependências e / ou recursos não utilizados.

Podemos monitorar fontes como esta banco de dados de código aberto por vulnerabilidades Por WhiteSource, nos componentes.

Para garantir que seus componentes estejam seguros, é prudente verificar regularmente os bancos de dados de vulnerabilidades e aplicar os patches de segurança imediatamente, ajudando assim a permanecer protegido.

Autenticação quebrada

Essa vulnerabilidade ocorre quando os aplicativos da Web mal implementam técnicas de gerenciamento de autenticação / sessão, dando aos invasores acesso a contas que, de outra forma, não deveriam estar autorizadas a acessar.

Esse problema de segurança é mais disseminado na forma de ataques de força bruta e na exposição do ID / token da sessão de forma que possam ser facilmente roubados.

Exemplo de código incorreto 1:

Vamos dar o exemplo do snippet de código anterior. Ajustamos um pouco para enviar um 401Resposta (não autorizada) quando nenhum usuário é encontrado com um determinado email e senha.

Mesmo este é o código refatorado, ele ainda está vulnerável a este tópico (Broken Auth). Aqui, se usarmos uma senha errada, obteremos uma resposta 401, mas se a senha for fraca, podemos forçá-la a força bruta até que a adivinhem.

Reestruturação

Para evitar ataques de força bruta, basta usar um limite de taxa em nossa rota. Agora, o usuário tem três chances de se autenticar, após o que não poderá mais enviar solicitações nessa rota pelos próximos 15 minutos, obtendo uma resposta de 429 Pedidos demais.

O próximo tipo de vulnerabilidade neste tópico tem a ver especialmente com o gerenciamento de tokens da Web JSON mal.

Exemplo de código incorreto 2:

O próximo exemplo é encontrado com muita frequência nos sistemas de login:

Na maioria das vezes, o sistema de login usando JWT é implementado dessa maneira. Depois que o usuário envia as credenciais corretas, um token é gerado usando seu Eu iria ou outro único o valor e o token são enviados para o front-end, onde serão salvos dentro do aplicativo ou, se for necessária uma autenticação persistente, serão salvos dentro de cookies ou armazenamento local.

O problema dessa abordagem é que o token que deve ser protegido agora pode ser acessado por meio do código front-end, tornando-o vulnerável. Um código malicioso injetado no JavaScript front-end pode acessar cookies ou armazenamento local e roubar esse token.

Reestruturação

Esse problema pode ser superado com a próxima implementação.

Dessa vez, o token também é salvo em cookies, mas é salvo no código de back-end com o httpOnly , portanto, ele não pode ser acessado a partir de qualquer código em execução no front end. Para torná-lo mais seguro, o token é salvo com o assinado propriedade, que faz com que os cookies sejam assinados com uma chave secreta.

Você pode ir ainda mais longe e bloquear o http protocolo com o bandeira segura o que força o envio do cookie https

Exposição de dados confidenciais

Como o nome indica, essa vulnerabilidade é acionada quando um aplicativo da Web falha na proteção suficiente de dados confidenciais.

Embora mudanças legais recentes, como GDPR Para garantir que os dados confidenciais não sejam expostos, uma porcentagem significativa de aplicativos da Web não atende a esses requisitos.

Isso geralmente acontece quando os dados são transmitidos em texto não criptografado usando HTTP, SMTP e FTP ou algoritmos criptográficos fracos / antigos são usados.

Um cenário provável pode ser o seguinte:

Um site não usa nem aplica o TLS para todas as páginas. Um invasor monitora o tráfego de rede, baixa as conexões de HTTPS para HTTP, intercepta solicitações e rouba as informações enviadas, talvez até o cookie de sessão do usuário, acessando ou modificando os dados privados do usuário.

Outro cenário pode ser:

As senhas são armazenadas no banco de dados sem sal ou como hashes simples e fracos. Uma falha de upload de arquivo ou qualquer outro ataque permite que um invasor recupere o banco de dados de senhas. Depois, todos os hashes podem ser expostos com uma tabela arco-íris de valores pré-calculados, dando assim ao invasor a senha simples dos usuários.