Como enviar credenciais para o testing

Para avaliar as áreas autenticadas de uma aplicação, a Strike precisa de credenciais de acesso válidas. Enviar as credenciais corretamente é uma das etapas mais importantes do onboarding: se estiverem ausentes ou incompletas, o testing não consegue cobrir o que está atrás do login.

Este artigo explica onde enviá-las, quais tipos existem e quais credenciais é melhor fornecer.

Onde enviá-las

As credenciais são enviadas na segunda etapa do formulário de criação do asset, com o botão Add credential. Você pode adicioná-las ao criar o asset ou depois, editando-o na seção Details. Cada asset pode ter várias credenciais, e você pode combinar diferentes tipos.

Tipos de credenciais

Ao adicionar uma credencial, você escolhe o tipo de acordo com a forma de acesso à aplicação:

• User & Password: usuário e senha. É o caso mais comum, para aplicações com login padrão.

• Custom headers: para acessos autenticados por meio de headers específicos (por exemplo, um token em um header de autorização).

• Cookies: para acessos baseados em sessão, quando o acesso é mantido com cookies de sessão já estabelecidos.

• API Keys: se a aplicação é acessada por meio de uma API Key, você pode enviá-la como um custom header (por exemplo, um header de autorização com a key). É a forma de fornecer API Keys até que exista uma opção dedicada.

User & Password

Ao escolher User & Password, você preenche o username, a senha e o role esperado desse usuário. Em Advanced configuration, você pode configurar a autenticação de dois fatores (2FA) caso a aplicação exija.

Se a aplicação pedir 2FA no login, a Strike pode completar o segundo fator da mesma forma que um usuário real faria. A configuração (app de autenticação / TOTP ou código por e-mail) está detalhada no artigo Como adicionar autenticação de dois fatores (2FA) a uma credencial.

Custom headers

Use esse tipo quando a autenticação é resolvida por meio de headers específicos. Você envia o(s) header(s) necessário(s) (por exemplo, um header de autorização com seu token) para que a Strike acesse de forma autenticada.

Cookies

Use esse tipo quando o acesso é baseado em uma sessão já iniciada. Você envia os cookies de sessão que permitem à Strike manter o acesso autenticado durante o testing.

Quais credenciais e informações fornecer

Para que a Strike possa acessar de forma completa, recomendamos as seguintes opções, em ordem de preferência:

1. Usuário de teste registrado com um e-mail @strike.email (recomendado). Crie na aplicação um usuário de teste dedicado usando qualquer endereço @strike.email (por exemplo, [email protected] ou [email protected]). As caixas @strike.email são caixas de entrada reais administradas pela Strike: não é necessário criá-las nem compartilhar acesso a elas. A Strike lê automaticamente os e-mails de confirmação ou verificação que chegam ali, o que permite completar o cadastro do usuário e, se aplicável, o 2FA por e-mail.

2. Encaminhamento para um e-mail @strike.email. Se não for possível registrar um usuário novo, configure o encaminhamento dos e-mails dessa conta para um endereço @strike.email.

3. Usuário e senha com qualquer e-mail. Se, por motivos de compliance, não for possível usar um endereço @strike.email, forneça um usuário e senha com o e-mail usado habitualmente. ⚠ Esta é a opção menos recomendada. Como a Strike não tem acesso à caixa de e-mail associada, é a mais propensa a travar: se o acesso exigir verificação por e-mail ou 2FA, não será possível concluir a verificação por conta da Strike. Nesse caso, combine uma alternativa em Additional notes (por exemplo, como resolver o 2FA).

Se a conta usa 2FA, recomendamos sempre a opção @strike.email, pois ela permite à Strike acessar o segundo fator diretamente por essa caixa.

Além das credenciais em si, forneça as informações de roles, permissões e privilégios de cada usuário. Você pode detalhar isso em Additional notes (veja a próxima seção). Isso é essencial para que a Strike avalie corretamente os controles de acesso e evite falsos positivos nos testes de autorização.

Campo "Additional notes": esclarecimentos importantes

Dentro de Advanced configuration existe o campo Additional notes, onde vale detalhar tudo o que ajude a usar as credenciais corretamente e tornar a avaliação mais precisa. Vale esclarecer ali, por exemplo:

• Se o acesso é feito por SSO (single sign-on) e como ele funciona.

• Se há uma forma específica de resolver o 2FA.

• Se você quiser fornecer acesso à caixa de e-mail associada à credencial, esses dados podem ser incluídos ali.

• Os privilégios e acessos do role: o que esse usuário pode fazer, a que tem acesso e as particularidades de suas permissões. Isso é essencial para avaliar corretamente os controles de acesso e evitar falsos positivos nos testes de autorização.

• Como funciona o modelo de permissões (RBAC) e como os usuários são gerenciados (criação, desativação e modificação).

• Qualquer particularidade dos mecanismos de authentication / authorization.

Quanto mais informação for fornecida, menos idas e vindas e mais rápido o testing pode começar.

Perguntas frequentes

Onde as credenciais são enviadas?

No asset, com o botão Add credential. Você pode fazer isso ao criar o asset ou depois, editando-o em Details.

Quais tipos de credenciais podem ser enviados?

Três, de acordo com a forma de acesso à aplicação: User & Password (usuário e senha), Cookies (acessos por sessão) e Custom headers (autenticação por headers). As API Keys também são enviadas, como um custom header.

É possível enviar mais de uma credencial em um asset?

Sim. Um asset pode ter várias credenciais, e você pode combinar diferentes tipos.

Quais credenciais é melhor fornecer?

O ideal é um usuário de teste dedicado registrado com um endereço @strike.email, pois a Strike lê automaticamente os e-mails que chegam a essa caixa (confirmação, verificação, 2FA por e-mail). Se isso não for possível, os e-mails podem ser encaminhados para um endereço @strike.email. E se o compliance não permitir usar esse domínio, um usuário e senha com qualquer e-mail funciona (esta é a opção menos recomendada, pois pode travar em verificações por e-mail ou 2FA).

É necessário criar a caixa @strike.email ou dar acesso a ela?

Não. As caixas @strike.email são caixas de entrada reais administradas pela Strike. Só é necessário registrar o usuário de teste na aplicação usando um endereço @strike.email (por exemplo, [email protected]); a Strike lê os e-mails do lado dela.

É possível atualizar as credenciais depois de criar o asset?

Sim. O asset é editado em Details, e você pode atualizar ou adicionar credenciais sempre que precisar.

Minha aplicação usa 2FA, como configuro?

Ao adicionar uma credencial de User & Password, em Advanced configuration você pode configurar o 2FA. O detalhe de cada método está em Como adicionar autenticação de dois fatores (2FA) a uma credencial.

omo o acesso funciona se a aplicação usa SSO?

Indique no campo Additional notes que o acesso é feito por SSO e como ele funciona, para que a equipe possa acessar corretamente.

Para que servem as "Additional notes"?

É um campo dentro de Advanced configuration, disponível em todos os tipos de credencial. Vale esclarecer ali roles e privilégios, SSO, formas específicas de 2FA, ou acesso à caixa de e-mail associada.

O que acontece se uma credencial for enviada incorretamente?

O Pre-flight Check roda antes de o testing começar e detecta problemas de acesso. Se o login falhar (por exemplo, senha incorreta), isso fica registrado para que a credencial possa ser corrigida e o testing possa ser executado novamente, sem perder cobertura.