Advanced Settings

Advanced settings control various aspects of WAAS features.

Prisma Sessions

Prisma sessions are intended to address the problem of "Cookie Droppers" by validating clients support of cookies and Javascript before allowing them to reach the origin server. 
Once enabled, WAAS serves an interstitial page for any request that does not include a valid Prisma Session Cookie. The interstitial page sets a cookie and redirects the client to the requested page using Javascript.
A client that doesn’t support cookies and Javascript will keep receiving the interstitial page. Browsers can easily proceed to the requested page, and once they possess a valid cookie they will not encounter the interstitial page.
Users should take caution when enabling Prisma Session Cookies along with API protection as APIs are often accessed by "primitive" automation clients. Avoid enabling Prisma Session Cookies on such endpoints unless you are certain all clients accessing the protected API endpoints support BOTH cookies AND Javascript. Users are able to allow "primitive" clients by adding them as user-defined bots and setting the bot action to Allow. Allowed user-defined bots will not be served with an interstitial page and their requests will be forwarded to the protected application.
Prisma Session Cookies set by WAAS are encrypted and signed to prevent cookie tampering. In addition, cookies include advanced protections against cookie replay attacks where cookies are harvested and re-used in other clients.

Ban

Ban action is available in the App firewall, DoS protection and Bot protection tabs. If triggered this action would prevent access to the protected endpoints of the app for a time period set by users (default is set to 5 minutes.)
If Prisma Session Cookies are enabled, users are able to apply ban by either Prisma Session Id or by IP.

Body Inspection

Body inspection can be disabled or limited up to a configurable size (in Bytes).
WAAS body inspection limit is 131,072 Bytes (128Kb)

Remote Host

This option is intended to defend web applications running on remote hosts which can not be protected directly by WAAS (e.g. Windows Servers).
Remote host option is only available for WAAS host rules.
Use-case scenario:
  1. A "middle-box" host instance with WAAS supported OS should be set up.
  2. Traffic to the web application should be directed to the "middle-box" host.
  3. Ports on the "middle-box" host to which traffic is directed to should be unused (WAAS will listen on these ports for incoming requests).
  4. WAAS host rule with Remote host settings should be deployed to protect the "middle-box" host.
  5. Incoming traffic to the "middle-box" host will be forwarded to the specified address (resolvable hostname or IP address) by WAAS.
WAAS sets the original Host HTTP header value in the X-Forwarded-Host HTTP header of the forwarded request. The Host header is set to the hostname or IP mentioned in the WAAS settings.
Use of TLS and destination port is determined by the endpoint configuration in the App definition tab.
Example:
The following protected endpoints are defined in the App definition tab:
Remote host has been configured as follows:
Expected result would be as follows:
  • HTTPS traffic to www.example1.com on port 443 would be forwarded via HTTPS to www.remotehost.com
  • HTTP traffic to www.example1.com on port 80 would be forwarded via HTTP to www.remotehost.com
Protected endpoints with TLS enabled will not forward non-TLS HTTP requests.

Customize WAAS response message

Users can customize the response HTML and HTTP status code that are returned by WAAS when a or effect occurs:
  • Prevent response code
    - HTTP response code
  • Custom WAAS response message
    - HTML code to be served. Click on for a preview of the rendered HTML code.
User-provided HTML must start and end with HTML tags.
Javascript code will not be rended in the preview window.

Recommended For You