As carteiras criptografadas e as trocas criptográficas podem sofrer ataques de hackers (ou estupidez de usuários, desenvolvedores, bem como problemas com a lógica do sistema). O teste poderia ajudar a identificar vulnerabilidades e problemas na lógica do aplicativo, no entanto, ainda não encontrei uma metodologia formalizada na qual seria escrito o que deveria ser prestado atenção durante o teste. Depois de testar uma dúzia de trocas e carteiras, decidi formalizar o procedimento para testá-los, interessados, bem-vindos ao gato.
Ao testar trocas e carteiras, chamei a atenção para o funcionamento delas e formulei os aspectos de seus testes abaixo na forma de uma pequena técnica, mas em ordem.
Primeiro de tudo, você precisa entender o que é importante para o cliente? É importante para o cliente que o dinheiro da troca ou da carteira e a preservação dos dados pessoais dos usuários não sejam roubados. E, na verdade, cada troca ou carteira, na maioria das vezes, é um site ou aplicativo da Web, o cliente deseja realizar uma simulação de um ataque de hacker, ou seja, Teste de caixa preta (consulte a Tabela 1), mas, para concluir os testes, o teste de caixa cinza é escolhido com mais frequência (consulte a Tabela 1).
Para testar a lógica do trabalho, você precisa de uma criptomoeda de teste. E uma vez que cada bolsa tem suas próprias restrições ao depósito / retirada de fundos, o valor da criptomoeda deve ser pelo menos o mínimo permitido para retirada e deve ser suficiente para realizar pelo menos 5 transações de compra e venda e / ou entrada e saída.
Tabela 1. Tipos de teste, dependendo das informações fornecidas.
| Tipo | Descrição do produto |
|---|
| Caixa preta | - o teste é realizado sem envolver a equipe técnica do cliente
|
| Caixa cinza | - contato com a equipe técnica do cliente
- adicionando contas que estão sendo testadas na "lista branca"
- o cliente fornece fundos (moedas) para teste
|
| Caixa branca | - suporte completo ao cliente
- fornecendo código fonte do aplicativo
- fornecimento de logs
- conceder acesso a diferentes privilégios
- provisão de fundos (moedas) no montante necessário para testar
|
Em Hacken, testamos vulnerabilidades na seguinte ordem:- Estudar informações publicamente disponíveis.
- Verificação por ferramentas automatizadas.
- Verifique no modo manual.
- Elaboração de relatórios.
Recursos de teste de trocas de criptografia e carteiras de criptografia1. Testando a verificação KYC - este é um requisito para a maioria das trocas de criptografia e ICOs.Esta seção discute o teste de downloads de arquivos (fotos ou capturas de tela de documentos que confirmam a identidade de uma pessoa).
- Verificando a capacidade de baixar arquivos executáveis para o servidor do sistema
- Verifique a possibilidade de roubo de documentos digitalizados - nomes e diretórios de arquivos de força bruta.
- Verificando o acesso não autorizado ao sistema de arquivos do servidor.
2. Teste de fundos insumo-produto- Verificar a exatidão dos números de arredondamento ao depositar / sacar fundos.
- Verificar a substituição do endereço da carteira ao depositar / retirar fundos (o erro mais simples não é verificar a carteira do remetente e do destinatário, mas é muito crítico).
- Verificar a lógica do trabalho ao depositar / retirar fundos.
- Verificando o desvio da confirmação da operação de compra e venda (código de autenticação de dois fatores, OTP, senha especial).
- Verifique as vulnerabilidades de retirada das condições de corrida.
- Verificar a possibilidade de ir além dos limites de entrada / saída de fundos.
3. Teste da compra e venda de criptomoedas (aplicável apenas a trocas)- Verificar a correção dos números de arredondamento ao comprar e vender fundos.
- Verificação da substituição do endereço durante a compra e venda.
- Verificar a lógica do trabalho ao comprar e vender fundos.
- Verificar a possibilidade de substituição ou modificação de uma ordem de venda.
- Verificando o desvio da confirmação da operação de compra e venda (código de autenticação de dois fatores, OTP, senha especial).
- Verificação da possibilidade de condição de corrida na implementação das operações de compra / venda.
- Verificando a possibilidade de falsificação de endereços de carteira.
Teste de Web Parts4. Testando o processo de registro- Verificando a filtragem dos parâmetros recebidos durante o registro.
- Verificação da funcionalidade de confirmação do usuário.
- Verificando a capacidade de iterar nomes de usuários, endereços de email e números de telefone.
- Verificando a possibilidade de ignorar a verificação captcha durante o registro.
- Verificando vulnerabilidades e lógica ao redefinir senhas e alterar dados.
5. Testando o processo de autenticação- Verificações de filtragem de autenticação.
- Verificando a possibilidade de selecionar um nome de usuário e senha para uma conta no dicionário (proteção contra força bruta).
- Verifique o bypass, verifique o captcha.
- Verificando desvio de autenticação de dois fatores
- Verificando a capacidade de desativar a autenticação de dois fatores.
- Verificando vazamento de dados durante a autenticação.
6. Testando as estruturas e tecnologias usadas no desenvolvimento do intercâmbioDurante o teste de vulnerabilidades, é necessário determinar as tecnologias e técnicas (estruturas) com as quais as trocas foram desenvolvidas. Assim, ao entender a tecnologia com a qual a carteira ou a troca foi desenvolvida, é possível encontrar uma possível exploração ou vulnerabilidades já descobertas em fontes abertas. É necessário verificar se todas as bibliotecas, estruturas e software de terceiros não possuem vulnerabilidades disponíveis publicamente no momento do lançamento ou a configuração correta dos sistemas de segurança (por exemplo, CloudFlare).
7. Teste OWASPA metodologia OWASP contém uma lista de verificação que examina todos os riscos de segurança possíveis para um site. Portanto, essa verificação permite identificar possíveis vulnerabilidades (bem, muito mais depende da
franqueza das mãos da experiência e das habilidades do testador)
Encontrado com mais frequência:
- Verificando os parâmetros de filtragem no back-end, pois geralmente são verificados apenas no front-end
- A ausência de sinalizadores de solicitação HTTP, o que não é crítico, mas pode levar ao cache de senhas ou à possibilidade de um ataque por Clickjacking
- Falta de gerenciamento de sessões: isso pode levar ao fato de que, quando um cookie é roubado ou um invasor tem acesso direto a um computador ou telefone, as operações de um usuário válido podem ser executadas
- Versões vulneráveis de serviços abertos
- Usando JSON Web Tokens (JWT), com algoritmos de criptografia fracos
8. Testando a API- Verificando vulnerabilidades da API, escrevendo um módulo de programa para interagir com a API e verificando possíveis vulnerabilidades lógicas no lado do cliente e na API.
- Use o Swagger para visualizar a estrutura da solicitação; é necessário entender o que precisa ser enviado ao servidor e, assim, verificar a vulnerabilidade da API.
9. Testando WebSocketsSoftware comumente usado para teste:- Burpsuite
- Acunetix
- Zenmap
- Owasp zap
- Sqlmap
E outras ferramentas, conforme necessário.
Conclusão:Neste artigo, tentei formalizar e estruturar a metodologia de teste de trocas, aplicada em mais de 10 casos de teste de trocas e carteiras. Tomamos essa metodologia como a principal metodologia para testar trocas em
Hacken . Hoje, a indústria de tecnologias blockchain, soluções descentralizadas e criptomoedas está no auge da popularidade. As perguntas frequentes e os manuais ficam desatualizados muito mais rapidamente do que a Lei de Moore; portanto, o artigo não afirma ser um manual excepcional para testar trocas de criptografia, apenas expressa a experiência adquirida durante a repetição repetida deste procedimento.