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

    Related Documentation


    Applications Overview

    You may want to secure multiple web applications or web sites using the same deployment of WebApp Secure. To facilitate this, you can create multiple applications using the Web UI or Configuration CLI, each with their own configuration options.

    All configuration items in the main sections of the Web UI are known as global parameters, except for the Applications section. Each configured application will inherit these global settings unless you specify that they should be overridden. Likewise, if you change a setting on the global level, it will be changed in every configured application, unless you have specifically overridden it.

    Adding an application using the Applications configuration menu allows you to override certain parameters within the context of a given application. When you add an application, you tell WebApp Secure the following: Any requests whose hostname matches the regular expression you have specified should be subject to the values you have overridden within the context of the application configuration. To override a value, click Applications in the left navigation of the Web UI, and then click the corresponding link to edit the desired application. Not all parameters can be overridden; for example, backups-related configuration is global-only.

    When using the configuration CLI, any parameter that does not start with applications. is a global parameter. You may execute the info command to view information about whether or not a given parameter can be overridden. To override a parameter for an application in the CLI, you use the application's slug, or short name, to create a prefix. For example, overriding "processors.basic_auth.enabled" for the application whose slug is "myapp", can be accomplished by executing the command set applications.myapp.processors.basic_auth.enabled false.

    Since most discrete web applications are on different application servers, the most commonly overridden parameter is the collection of backend servers.

    If your desired configuration requires further granularity, WebApp Secure also allows you to configure Pages which apply a regular expression to the path component of the URL, rather than the domain component, and allow a subset application of parameters to be overridden further.

    As an example, let's say that you want to use WebApp Secure to protect and You would set up two applications. The first would specify www\.example\.com as the pattern, and you would specify your web server as the backend. The second would specify blogs\.example\.com as the pattern, and you would specify your blog system's application server as the backend. Globally, since most of your infrastructure uses Apache, you have left the Basic Authentication Processor enabled on the global level. Your blog site, however, uses Nginx, and so a honeypot of a fake Apache configuration file would be a dead giveaway. Using the Applications configuration screen, you can override the setting to disable this processor for the blog site. Additionally, since the blog site uses WordPress, you might want to enable the Application Vulnerability Processor -- but not for your www site -- so you can use the Applications configuration screen to enable the Application Vulnerability Processor for the blog site.

    Continuing the example, let's say that your webmaster is running a campaign using Google Analytics, and it is found that the Query String Processor is injecting a fake parameter that is conflicting with the tracking of this campaign, but only under the "fribjatz" directory of the www site. Adding a Page with a pattern of "^/fribjatz(/.*)?$" would enable you to turn off the Query String Processor for any pages on the site that are in the "fribjatz" directory.


    Related Documentation


    Published: 2014-06-27