Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Response Processors: Support Processor

    When a user is blocked or otherwise responded to using one of the countermeasures, this processor provides a way to identify which profile is associated with a user, and to then allow those responses to be deactivated at the discretion of the IT administrator. For example, if a user were to get a 404 error when asking for a PDF document linked from the main site, and they then try to find the file by trying a bunch of different file names, they can eventually get blocked for performing a directory enumeration attack. When this happens, the blocked user can contact support for assistance getting access to the site again.

    This processor works by exposing a special administrative URL (defined in configuration) which the support team can access. When a support request comes in from a blocked users, the support representative can access this administrative URL which will provide another URL. The support representative should then provide this second URL to the affected user. The affected user can then visit that URL and get a special code. This code can be used to search for the profile and deactivate responses in the Web UI (profile list).

    If the affected user gets a code of "00000000000000000000" (all zeros), this means that the user is not identified as an attacker and therefore is not being blocked or responded to with a counter response from WebApp Secure. As such, other causes of the user's inability to access the site should be investigated.

    DO NOT GIVE OUT THE ADMINISTRATIVE URL. It is only used to get a fresh URL that is safe to provide to the affected user. If the administrative URL is leaked to the public, it should be changed immediately.

    The overall workflow is as follows:

    1. User is blocked or otherwise responded to with a countermeasure.
    2. User calls support for assistance.
    3. Support accesses the administrative URL.
    4. Support copies the newly created URL in the response and provides to the affected user.
    5. The affected user accesses the newly created URL and provides the resulting code to support.
    6. Support or an Admin then logs into the Web UI, clicks on the profile graph to get a list of profiles, and then searches for the code.
    7. Support or Admin reviews user's list of incidents to verify the user was responded to in error. If so, the Support or Admin disables the responses.

      Note: Note that the "block" response is by default, configured to return the code. So if a user has been blocked, steps 3-5 can be omitted, and the user can simply provide the code specified in the block message to support. For all other responses, the full workflow needs to be followed, because there is no other way to obtain the code.

    Table 1: Support Processor Configuration Parameters



    Default Value



    Processor Enabled



    Whether traffic should be passed through this processor.


    Private Support URL



    The URL a support representative would access to get additional details about how to provide support to users who are having issues that can be WebApp Secure related. If the value is "ABC", then the private URL would be It is absolutely imperative that this URL not be leaked to non-internal users. If it is leaked, it must be changed immediately.

    Public Support URL Salt



    A random value used to ensure that support URLs are not predictable. This can be any random string 30 characters in length.

    Public URL Expiration



    The number of days a public support URL remains valid for. After this many days, the URL will no longer provide support information. This is to prevent any issues from a public support URL being leaked.

    Published: 2015-02-04