Define authentication for testing

If your target requires authentication, you need to create a test account for XBOW and configure how XBOW should authenticate during testing.

Publicly accessible targets

If your target is publicly accessible without authentication, on the “Target configuration” page:

  • Lightspeed users select I want to perform an unauthenticated test
  • Enterprise users leave the “Credential set” area blank.

Then see Configure your server to allow XBOW requests.

Define authentication details

On the “Target configuration” page, use the “Credential set” area to tell XBOW how to log in to your target using a test account. For guidance on creating a test account, see Using a dedicated test account.

Supported authentication methods:

Note: If your target uses account lockout mechanisms, repeated authentication attempts can interrupt your assessment by triggering lockouts. If possible, we recommend turning off lockout mechanisms for the duration of your assessment.

Username and password

  1. Define the Username and Password of the account to use for testing.
  2. If the account uses multi-factor authentication (MFA) with Time-based One-Time Password (TOTP), configure MFA access:
    • Allow XBOW to receive email (for email-based MFA): Click to create a temporary email address for MFA during testing.
    • Upload OTP QR code (for authenticator apps): Upload an image file with the QR code used to add the account to an authenticator.
    • Paste an OTP URL (for authenticator apps): If you have the OTP URL (starting with otpauth://), copy it to your clipboard and use the paste button to upload it.
  3. If the account supports single sign-on (SSO) with a link sent to users by email, click Allow XBOW to receive email to create a temporary email address. Supported for Okta and similar identity and access management systems (IAM).

Tip: XBOW does not support TOTP sent using SMS or other forms of MFA. If your target uses an unsupported form of MFA, we recommend temporarily disabling MFA for the duration of the test.

If authentication requires users to receive email and click a link in the message, click Allow XBOW to receive email to create a temporary email address for validating accounts.

Social login

If your target supports authentication using a social account, enter the username and password for that account in the Username and Password fields.

  • Supported: GitHub and Microsoft accounts
  • Not supported: Google accounts. Google blocks XBOW test requests even after successful authentication.

Basic HTTP authentication and static bearer token

  1. Scroll down the page to the Authorization header section and click to expand it.

  2. From the dropdown menu, select an authentication option (default is None):

    • Basic auth: Use to authenticate with a username and password.
    • Bearer token: Use to authenticate with a static bearer token or API key.
    • Custom: Use to authenticate with a custom value.

  3. By default, XBOW will only include your authorization header in requests to attackable hosts. If you need to authenticate to other accessible hosts, select Include in requests to all hosts in assessment scope.

Note: Tokens and API keys need to be valid during the whole assessment process.

Provide additional guidance

This is not usually needed, but if you have a complex or unusual method of authenticating, you can give XBOW instructions on how to authenticate with the details you provide in the “Credential set” area.

  1. Locate the Specific authentication instructions section and click to expand it.
  2. Write step-by-step authentication instructions using the credentials you provided above. Write clear, detailed instructions that a human security tester could follow.

Add extra credentials for IDOR analysis

Insecure Direct Object Reference (IDOR) testing can use up to four additional accounts to build a richer understanding of the authorization model for the application. By comparing what different users can access, XBOW detects cross-user data leaks, privilege escalation, and authorization flaws that are invisible when you test with a single account.

When you enable user credentials for IDOR analysis, you will see an extra field Role description. Use this to describe each role. For example:

  • Test account for attacking, employee with access to stock control and own personal data
  • Second employee with access to stock control and own personal data (horizontal testing)
  • Store manager with access to the admin panel (vertical testing)
  • HR employee with additional access to employee database (vertical testing)

Note: IDOR analysis is available to Enterprise users as a public preview release.

  1. Specify the first set of credentials.
  2. You must include a Role description that describes the options available the user account.
  3. Click Add credential set for IDOR to open the “Multi-account testing for IDOR” dialog box.
  4. Review the guidance and select Enable IDOR detection, then click Add credential set.
  5. Define the credentials and role for a second account. This can be a user at the same privilege level as the first user (for horizontal testing) or a higher-privilege user like an admin (for vertical testing).
  6. Define additional accounts as needed up to a total of five accounts, including the primary credential set.
  7. When you have added the credential sets that you want to use, verify that the “Primary credential set” is correct. This account is used to attack the asset during the assessment. By default, this is the first credential set. You can select an alternative attack account.

Under “Assessment guidance”, the “Attack strategy” card now shows an additional attack type is enabled. If you open the card, you will see that the “Insecure Direct Object Reference” checkbox is enabled.

Next steps

  1. Provide XBOW with context to guide testing (optional)
  2. Configure your server to allow XBOW requests