Validate results with canary tokens

  • Enterprise only

Canary tokens are secrets you hide in your application and challenge XBOW to retrieve. This is the only way to find and prove some types of vulnerability, for example: business logic flaws.

This approach is also a good way to get clear verification of SQL injection, local file read, or remote code execution vulnerabilities. In addition, using test files, tables, and servers ensures that there is no risk of exposing sensitive data.

Requirements

  • Generate a Globally Unique Identifier (GUID) to use as a canary token.
  • Store the canary token in a location that should not be accessible to the test account used by XBOW. If a canary is in a public field, the attack agents may find it without demonstrating a clear vulnerability.
  • Add full and clear details of the token to the assessment configuration. This ensures that attack agents do not waste attack credits looking for the token in the wrong location.
  • Use the test command generated by XBOW to verify that you have defined the location and identifier of each token correctly before running the assessment.

Tip: Each time you open the “Add canary” dialog in the assessment configuration page, a new GUID is generated. You can use this GUID or generate your own.

Add a canary token to your application

Supported canary token types:

  • Disk File: store a test file in a disk location that should not be accessible to the test account used for the assessment.
  • SQL Record: add a test record to a table that should not be accessible to the test account used for the assessment.
  • Internal Server: create a test internal server that should not be accessible to the test account used for the assessment.
  • Application Specific: place a canary token in a location that should not be accessible to the test account used for the assessment.

Disk File

Add a test file to your application to validate Local File Inclusion (LFI) or Remote Code Execution (RCE) without requiring the attacker to know anything about the file system.

  1. In your application, create a file such as /flag.txt and add a canary token: flag{GUID}.
  2. Make the file readable by all users, for example: chmod a+r.
  3. Store the file outside the document root of the web server so it will not be directly served to the public.

Ideally, store the file at the root of the file system (/flag.txt). If this is not possible, use a different non-public but world-readable location.

SQL Record

Add a test table to your application to validate a SQL injection attack without requiring the attacker to know anything about the schemas used by your application.

In your application, create a dedicated table for testing, for example:

CREATE TABLE xbflag (flag VARCHAR(128));
INSERT INTO xbflag VALUES (‘flag{GUID}’);

Internal Server

Run an internal web server to host a test file so you can validate Server-Side Request Forgery (SSRF) without requiring the attacker to know anything about your server architecture.

  1. Create an internal-only, web server that hosts a file with the value of the canary token.

    Example:

    nohup bash -c ‘while true; do echo -e “HTTP/1.1 200 OK\\r\\nContent-Length: 49\\r\\n\\r\\nflag{GUID}” | nc -l -p 8000; done’ >/dev/null 2>&1 &

  2. Give the server a hostname that resolves from within the target environment (for example, xbow-canary-web), so that you can reference it by name rather than IP address when you add a canary token to XBOW console.

Application Specific

Store a GUID in a custom location that should not be available to the test account used by XBOW to validate business logic vulnerabilities.

  1. Determine which elements of your application you want to test and verify that they are not accessible to the test account used by XBOW.
  2. For each element you want to include as a canary token, make a note of the details so you are ready to add them to the assessment configuration:
    • Name: a name to use as shorthand to refer to this canary token.
    • Location: where the canary token can be found, for example: Admin email for Org ID 6000, visible only in Settings.
    • Expected contents: the value stored, for example: admin-2@example.com.

Best practice: Be explicit when you define a location, include object identifiers, parent accounts, or context. Avoid vague descriptions like “admin email”.

Update the assessment configuration to add the canary details

  1. In the “Target configuration” page for the assessment, click Validation to open the dialog for sharing validation details.

  2. Click Add canary and then select a canary type.

  3. If you have already planted a canary token, enter the location and value of the canary token. Alternatively, copy the GUID from the XBOW dialog and store it in the suggested location, or a similar place, in the application.

  4. For most canary types, copy the verification command displayed and run it on your web server. Verify that the result of the command matches the expected result in the “Add canary” dialog exactly.

    For Application Specific canaries, use a privileged account to confirm the value exists and is private.

  5. If the test fails, revise the details in the dialog box.

  6. When you have successfully tested that you can retrieve the token, enable I have verified the canary is planted

  7. Click Save canary.

When the Validation dialog is open, the canary summary is displayed at the bottom. It is already saved to the configuration for the assessment.

Best practice

  • Rotate canary tokens after each assessment.
  • Remove test tables, files, or servers when you finish pentesting the application.
  • Configure your application to keep canary tokens out of logs or error messages.
  • Exclude the location and value of all canary tokens from any information you share with XBOW with the exception of the “Add canary” dialog. For example, ensure that they are not accidentally included in a source code archive.