Scanning live production environments

The following risks and suggestions should be considered before scanning a live site with AppScan.

When scanning a live site, you can use the predefined Production Site template. This template includes a specially selected Production Site test policy, as well as configuration settings designed to minimize the risk of damaging a live site, or causing Denial of Service to real users.

If you choose to use your own configuration or test policy, the following sections can help you configure your scan effectively.

Database may get filled with artificial information sent during scanning

You can reduce the impact of this by taking the following precautions:

  • Disable Automatic Form Fill (Scan Configuration > Automatic Form Fill > first check box).

    This will ensure that AppScan® does not fill forms automatically, submitting data that might flood a database, bulletin board or online forum system, or send unwanted email to an administrator or moderator account. However, you should be aware that doing this will limit AppScan® Standard's ability to reach areas of the site that are accessed by submitting forms. In this mode of operation, AppScan® will only scan areas of the site that can be accessed by following links (with or without parameters).

  • Create a test account for AppScan® to use.

    Using a test account makes it easier to track database changes (for example, to make sure that services are not actually ordered), and helps site administrators clean up site after scanning.

    Consider the following suggestions when creating the account:
    • Limit database access to test records only, so that modified records can be restored.
    • Ensure that new records created by the test account will be deleted.
    • Ensure that purchase orders (or other transactions) from the test account will be ignored.
    • If transactions have an impact (such as when dealing with stocks), allow the account access to test records only.
    • If the site has forums, allow the test account access to test forums only, so that real customers will not see the tests created during the Test stage.
    • If the site has different privileges for different accounts, set up more than one test account, with different privileges. This will ensure a more comprehensive scan of the site.
    • Do not create a test account with administrator-level access.

Risk of email flooding

When testing pages that use email notification, AppScan® generates many requests and may overload the site's email server.

One or more of the following suggestions can help dealing with this:

  • Temporarily change the email addresses on the pages being tested, so that email is sent to an invalid email address.
  • If practical, configure AppScan® to exclude those pages from the production scan.
  • Scan only one web server at a time, and prevent it from connecting to the SMTP server during the scan.
  • If you decide to leave Automatic Form Fill enabled, configure it to insert a unique value in the email field, so recipients can easily identify email generated by AppScan®.

Scanning through a proxy

If possible, avoid scanning through a proxy. While this is supported, the proxy sometimes obscures results.

Risk of scan getting locked out of the application

Some applications are configured to lock users out after a certain amount of incorrect login attempts. If this happens during the scan, obviously AppScan® will be unable to complete the scan.

To avoid this:

  • Disable Send tests on login and logout pages (Scan Configuration > Test Options).

Risk of causing application failure

To avoid the risk of AppScan® causing your live application to fail, you may want to deactivate invasive tests in the test policy. This will ensure that Denial of Service, Buffer Overflow, or other tests that might cause the application or web server to fail, are not sent.

Important: web applications often contain vulnerabilities that can only be discovered by invasive tests. It is not recommended that you omit invasive tests altogether. Instead, test your application for these kinds of vulnerabilities in coordination with your website owner or administrator, perhaps scheduling scans during off-peak hours when the application is likely to be idle.

To disable invasive tests in the current test policy:

  1. Open Configuration > Test Policy.
  2. Click on the Invasive column, to group all invasive tests together.
  3. Scroll down the invasive tests (tests for which the Invasive value is "Yes"), and deselect any that are currently selected, to exclude them from the scan.