Segurança
Checklist de Testes de Segurança para QAs
6 minutos de leitura
Talvez você imagine que para executar testes de segurança para QAs é necessário ter incríveis habilidades hackers e digitar em um terminal com background preto e letras verdes. No entanto, muitas falhas de segurança são simples e podem ser detectadas no dia a dia do desenvolvimento de software.
Na edição mais recente do OWASP Top 10:2021, uma lista das 10 principais falhas de segurança, o quarto colocado foi o Design Inseguro. Isso indica que os problemas relacionados aos testes de segurança para QAs não surgem do nada, mas se propagam desde o início do desenvolvimento do produto e podem ser evitados e identificados durante os testes.
Assim, o objetivo dessa publicação é listar e explicar alguns testes fáceis que podem ser feitos pelos QAs (e por que não por qualquer outro integrante do time?) no seu trabalho rotineiro e que irão proteger a aplicação contra as falhas mais comuns.
Checklist de segurança
O checklist para os testes de segurança para QAs abaixo foi baseado em algumas das falhas listadas no OWASP Top 10:2021 e pode ser executado durante o desenvolvimento e testes das aplicações de software.
- 1. Controle de acesso
- 2. Criptografia de dados
- 3. Tratamento da entrada de informações
- 4. Exposição de serviços
1 | Controle de acesso
O controle de acesso é responsável por garantir que o usuário faça apenas o que ele tem autorização para fazer. Nessa validação, é interessante responder três perguntas:
- O serviço valida se o usuário está logado?
- O serviço valida se o usuário logado utilizar determinada funcionalidade?
- O serviço valida se o usuário utilizar determinada funcionalidade da forma como está fazendo?
Para exemplificar, imagine uma aplicação em que o usuário consulta os pedidos que fez em uma loja online. Os testes para responder às perguntas acima ficariam assim:
- Validar se o usuário consegue consultar pedidos apenas se estiver logado.
- Validar se o usuário tem direito de consultar pedidos (neste caso, é provável que todos tenham).
- Validar se o usuário consegue consultar apenas os pedidos que foram feitos por ele.
Aplicação do teste
Considere que a URL desta aplicação para consultar o pedido é a seguinte: https://lojaonline.com.br/consultar?pedido=129807
1. O usuário está logado?
Para validar, tente acessar a URL sem passar as credenciais de autenticação (em uma guia anônima por exemplo). Não deve ser possível executar essa ação.
2. O usuário pode consultar pedidos?
Nesse caso, é provável que todos os usuários tenham autorização para consultar pedidos. Entretanto, fique atento para aplicações que possuem permissões específicas para cada tipo de usuário (admin, user, etc). Verifique se o usuário consegue executar apenas as ações que têm autorização.
3. O usuário pode consultar apenas os seus pedidos?
Observe que na URL existe um parâmetro “pedido=129807”. Tente consultar a URL alterando esse valor para o número de um pedido que não pertence ao usuário. Essa ação também não deve ser possível.
Dicas importantes
- Além do frontend, verifique as requisições feitas para a API. As validações devem ser realizadas pelo backend também.
- Nesse exemplo, o valor do pedido estava sendo passado na URL, mas informações também podem ser passadas por cabeçalhos, corpos de requisições e outras formas. Seja criativo na sua exploração.
- Aprofunde seu conhecimento: conteúdo base.
2 | Criptografia de dados
Dados sensíveis são todos aqueles que podem identificar uma pessoa. Eles devem ser trafegados e armazenados com cuidado, sendo que cada tipo de dado exige um tratamento específico conforme sua criticidade.
Nesse quesito, é comum que ocorram falhas para armazenar e trafegar dados com criptografia que utilizam algoritmos e protocolos fracos, ou então que não estão utilizando nenhuma criptografia.
Por exemplo, as senhas utilizadas para autenticação do usuário devem ser armazenadas no banco com criptografia irreversível, utilizando SHA2 ou tecnologias semelhantes e com um “valor salt” que garante a aleatoriedade do hash.
Aplicação do teste
1. Uso do HTTPS
Verifique se o frontend e as requisições backend estão utilizando o protocolo HTTPS. Tente acessar a URL ou realizar a chamada do endpoint da API utilizando HTTP no início. Em nenhum dos casos isso deve ser possível, pois significaria que os dados estão sendo trafegados sem estarem criptografados entre o browser e o servidor
2. Senhas salvas no banco de dados
Para verificar se as senhas estão armazenadas corretamente, acesse o banco de dados e consulte o campo que armazena essa informação. Você deve visualizar um hash e nunca um texto simples. Além disso, questione os desenvolvedores sobre qual algoritmo de criptografia está sendo utilizado. SHA1, MD5, Base64 e AES são exemplos de criptografias que não devem mais ser utilizadas para senhas
3. Informações sensíveis desnecessárias
Sugira que sejam salvas somente as informações realmente necessárias. Dessas que forem salvas, verifique se sua aplicação exibe ou retorna somente as que necessita. Por último, procure que as informações sensíveis sejam criptografadas e parcialmente ocultas.
Dica importante
- Aprofunde seu conhecimento: conhecimento base.
3 | Tratamento da entrada de informações
Todos os locais da aplicação que permitem ao usuário enviar uma informação podem estar suscetíveis a falha de injeção. Inputs, formulários, parâmetros de URL, corpos de requisições e outros podem permitir que um comando indesejado seja enviado.
Os tipos de injeção mais comuns são os de SQL e NoSQL. Para exemplificar uma injeção SQL, imagine uma aplicação que realize a busca de produtos em uma loja online e que tem a seguinte URL: https://lojaonline.com.br/busca?termo=Geladeira
Essa URL retorna uma lista de produtos que tenham o termo pesquisado no nome. No código, o que será feito é buscar todos os produtos que tenham o termo “Geladeira”. Em uma aplicação com falha, o termo informado na busca seria concatenado da seguinte forma:
Isso resultaria na seguinte query executada no banco:
Para executar uma injeção SQL, o atacante poderia informar o seguinte no termo: Geladeira’ OR 1=1–, ficando a URL da seguinte forma: https://lojaonline.com.br/busca?termo=Geladeira’ OR 1=1–
Como a URL não aceita caracteres especiais, seria necessário utilizar um URL Encoder para deixar a URL da seguinte forma: https://lojaonline.com.br/busca?termo=Geladeira%27%20OR%201%3D1%20–
O resultado no banco seria:
Isso faria com que a query executada retornasse todos os produtos do banco. Neste caso, outros comandos poderiam ser executados, permitindo que o atacante capturasse ou alterasse outras informações.
Aplicação do teste
1. SQL Injection
Em aplicações que utilizam bancos como SQL Server, Oracle e outros do tipo, procure por entradas de valores em URLs de frontend e de chamadas de API, em corpos de requisições ou então em formulários, especialmente as entradas que sejam de texto.
Depois de encontrado, tente enviar um comando SQL no texto do parâmetro. Um exemplo comum é o ‘ OR 1=1–, que fica como %27%20OR%201%3D1%20–. Normalmente, um erro deve ser retornado informando que o valor não é válido para o parâmetro.
2. NoSQL Injection
Já nas aplicações que utilizarem bancos como o MongoDB, procure por estas mesmas entradas e tente executar funções como a seguinte: (function(){return geladeira})(), que fica como %28function%28%29%7Breturn%20geladeira%7D%29%28%29. Não deve ser possível executar nada semelhante.
3. Questione os devs
Pergunte para os desenvolvedores se eles estão tratando as entradas para evitar falhas de injeção. Você também pode pedir para verificar o código.
Dicas importantes
- Mesmo que o ataque seja mal sucedido, o atacante pode obter mensagens de erro que identifiquem a tecnologia utilizada (ex.: ORA-07202 que identifica que a aplicação utiliza Oracle) e, dessa forma, consiga direcionar seus ataques.
- Para realizar o encode de parâmetros, você pode utilizar este site.
- Aprofunde seu conhecimento: conhecimento base.
4 | Exposição de serviços
Em algumas situações, podem estar acessíveis para qualquer pessoa na internet aplicações que não deveriam. Podemos citar como exemplo ambientes de testes e swaggers.
É usual que os ambientes de testes não tenham as mesmas configurações de segurança que o ambiente de produção e, por isso, acabam ficando mais expostos a ataques e devem estar inacessíveis.
Aplicação do teste
1. Ambientes de teste
Ambientes de teste como DEV e HML devem ser acessíveis somente com o uso de VPN, da rede privada da empresa ou mediante login. Para verificar, tente acessar a URL do seu ambiente de testes em um computador pessoal ou sem fazer uso da VPN/Rede que costuma utilizar.
2. Swaggers
O swagger é utilizado para gerar documentação e descrever serviços de API REST e também não devem estar acessíveis ao público geral da internet. Para validar, o mesmo teste feito com o ambiente de testes pode ser realizado: tente acessar o swagger em um computador pessoal ou sem fazer uso da VPN/Rede que costuma utilizar e ele não deve estar acessível.
Dica importante
- Aprofunde seu conhecimento: conhecimento base.
Conclusão
O que foi exposto acima é o básico para iniciar seus testes de segurança para QAs, mas ainda há muito mais para explorar. Lembre-se que, além de melhorar o produto que o seu time entrega, você estará ajudando a combater criminosos e a tornar a internet mais segura.
