Como enviar credenciais para o testing

Para avaliar as áreas autenticadas de uma aplicação, a Strike precisa de credenciais de acesso válidas. Cadastrar bem as credenciais é um dos passos mais importantes do onboarding: se estiverem faltando ou incompletas, os testes não conseguem cobrir o que está por trás do login.

Este artigo explica onde elas são cadastradas, quais tipos existem e quais credenciais é recomendável fornecer.

Onde são cadastradas

As credenciais são cadastradas na etapa Settings do formulário de criação do asset, com o botão Add credential. Elas podem ser adicionadas ao criar o asset ou mais tarde, editando-o a partir da seção Details. Cada asset pode ter várias credenciais, e é possível combinar tipos diferentes.

Você também pode configurar as credenciais de um asset a partir de uma Threat Emulation, com Set up na etapa de Scoping. Para ver como as credenciais são compartilhadas entre o asset e a Threat Emulation, consulte Como a configuração é herdada entre um asset e uma Threat Emulation.

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, ela pode ser cadastrada como um custom header (por exemplo, um header de autorização com a key). Esta é 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 papel esperado desse usuário. Em Advanced configuration, é possível configurar a autenticação de dois fatores (2FA) se a aplicação exigir.

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 em Como adicionar autenticação de dois fatores (2FA) a uma credencial.

Custom headers

Use este tipo quando a autenticação é feita com headers específicos. Você cadastra o header ou os headers necessários (por exemplo, um header de autorização com seu token) para que a Strike acesse de forma autenticada.

Cookies

Use este tipo quando o acesso se baseia em uma sessão já iniciada. Você cadastra os cookies de sessão que permitem à Strike manter o acesso autenticado durante os testes.

Quais credenciais e informações fornecer

Para que a Strike possa acessar de forma completa, recomendam-se 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 e-mail 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 registro 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 novo usuário, você pode configurar o encaminhamento dos e-mails dessa conta para um endereço @strike.email.

3. Usuário e senha com qualquer e-mail. Se, por razões de compliance, não for possível usar um endereço @strike.email, forneça um usuário e senha com o e-mail que você usa normalmente. 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, a Strike não conseguirá completar a verificação por conta própria. Nesse caso, é recomendável combinar uma alternativa em Additional notes (por exemplo, como resolver o 2FA).

Se a conta usa 2FA, recomenda-se sempre a opção @strike.email, porque ela permite à Strike acessar o segundo fator diretamente nessa caixa de e-mail. Para ver em detalhe como cada opção impacta a cobertura, consulte Como fornecer credenciais de teste para o agente de IA da Strike.

Além das credenciais em si, forneça as informações de papéis, permissões e privilégios de cada usuário. Essas informações podem ser detalhadas em Additional notes (veja a próxima seção). Isso é fundamental para que a Strike avalie bem 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 é recomendável detalhar tudo o que ajude a usar as credenciais corretamente e a tornar a avaliação precisa. Ali vale esclarecer, por exemplo:

• Se o acesso é feito por SSO (single sign-on) e como 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 papel: o que esse usuário pode fazer, a que tem acesso e as particularidades de suas permissões. Isso é fundamental para avaliar bem 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, exclusão e modificação).

• Qualquer particularidade dos mecanismos de authentication / authorization.

Quanto mais informações você fornecer, menos idas e vindas e mais rápido os testes podem começar.

Perguntas frequentes

Onde as credenciais são cadastradas?

No asset, com o botão Add credential. É possível fazer isso ao criar o asset ou depois, editando-o a partir de Details. Elas também podem ser configuradas a partir de uma Threat Emulation, com Set up.

Quais tipos de credenciais podem ser cadastrados?

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 podem ser cadastradas, como um custom header.

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

Sim. Um asset pode ter várias credenciais, e é possível combinar tipos diferentes.

Quais credenciais é recomendável fornecer?

O ideal é um usuário de teste dedicado registrado com um endereço @strike.email, porque a Strike lê automaticamente os e-mails que chegam a essa caixa (confirmação, verificação, 2FA por e-mail). Se não for possível, você pode encaminhar os e-mails para um endereço @strike.email. E se, por compliance, não for possível usar esse domínio, um usuário e senha com qualquer e-mail (é a opção menos recomendada, porque 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 e-mail reais administradas pela Strike. Basta 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 a partir de Details, e você pode atualizar ou adicionar credenciais quando necessário.

Minha aplicação usa 2FA. Como configuro?

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

Como é feito o acesso se a aplicação usa SSO?

Indique no campo Additional notes que o acesso é feito por SSO e como 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. Ali vale esclarecer papéis e privilégios, SSO, formas específicas de 2FA ou acesso à caixa de e-mail associada.

O que acontece se uma credencial for cadastrada incorretamente?

O Pre-flight Check é executado no início de cada execução e detecta problemas de acesso. Se o login falhar (por exemplo, por uma senha incorreta), a execução não começa e você vê um aviso com o problema. Corrija a credencial e clique em Retry. O Pre-flight Check não consome créditos. Para mais detalhes, consulte Como funciona o Pre-flight Check.