End-of-Life (EoL)

Deploying WAAS

WAAS (Web-Application and API Security) can secure both containerized and non-containerized web applications. To deploy WAAS, create a new rule, and declare the entity to protect.
Although the deployment method varies slightly depending on the type of entity you’re protecting, the steps, in general, are:
  1. Define rule resource.
  2. Define application scope.
  3. Enable relevant protections.

Understanding WAAS rule resources and application scope

The WAAS rule engine is designed to let you tailor the best-suited protection for each part of your deployment. Each rule has two scopes:
  • Rule resources.
  • Application list.

Rule Resources

This scope defines, for each type of deployment, a combination of one or more elements to which WAAS should attach itself in order to protect the web application:

Application List

This scope defines the protected application’s endpoints within the deployment as a combination of one or more of the following:
  • - For containerized applications, the internal port on which the application is listening. For all other types, the externally facing port.
  • - Default setting is set to * (wildcard indicating all hostnames)
  • - Lets you apply protection policy on certain paths of the application (e.g. "/admin", "/admin/*", etc.)
  • - TLS certificate to be used when expecting encrypted inbound traffic.
To better illustrate, consider the following deployment scenario for a web application running on-top of an NGINX cluster:
In this example, different policies apply for different parts of the application. The steps for deploying a WAAS rule to protect the above described web application would be as follows:
  1. Define rule resources
    - The rule will apply to all containers created from the nginx image.
  2. Define protection policy for 'login', 'search' and 'product' endpoints
    - Set OWASP Top 10 protection to "Prevent" and geo-based access control to "Alert".
  3. Define protection policy for the application’s API endpoints
    - Set OWASP Top 10 and API protection to "Prevent" and HTTP header-based access control to "Alert".
Once the policy is defined, the rule overview shows the following rule resource and application definitions:
  • - Protection is applied to all NGINX images
  • - We deployed two policies each covering a different endpoint in the application (defined by HTTP hostname, port and path combinations)

Deploying WAAS

Deploying WAAS for Containers

To deploy WAAS for containerized web applications, create a new rule, specify the image name, define application endpoints and select protections. WAAS only needs to be applied to images that transmit and receive HTTP/HTTPS traffic.
  1. Open Console, and go to
    Defend > WAAS
    .
  2. Select the
    Container
    tab.
  3. Click
    Add Rule
    .
  4. Enter a
    Rule Name
    and
    Notes
    (Optional) for describing the rule.
  5. Define
    Rule Resources
    .
    The rule resource section defines for each type of deployment a combination of image names and one or more elements to which WAAS should attach itself in order to protect the web application:
    Applying a rule to all images using a wild card (*) is invalid - instead, only specify your web application images.
  6. Click
    Add New App
    .
  7. In the
    App Definition
    tab, specify the endpoints in your web application that should be protected. Each defined application can have multiple protected endpoints. If you have a Swagger or OpenAPI file, click
    Import
    , and select the file to load. Otherwise, skip to the next step to manually define your application’s endpoints.
  8. If you do not have a Swagger or OpenAPI file, manually define each endpoint by specifying the host, port, and path.
    1. In the
      General App Setup
      tab, click
      Add Endpoint
      .
    2. Specify endpoint details:
    3. Enter
      Port (required)
      Specify the TCP port listening for inbound HTTP traffic.
    4. Enter
      HTTP Hostname
      (optional, wildcards supported).
      HTTP host names are specified in the form of [hostname]:[external port].
      External port is defined as the TCP port on the host, listening for inbound HTTP traffic. If the the value of the external port is "80" for non-TLS endpoints or "443" for TLS endpoints it can be omitted. Examples: "*.example.site", "docs.example.site", "www.example.site:8080", etc.
    5. Enter
      Path
      (optional, wildcards supported):
      Base path for WAAS to match on, when applying protections.
      Examples: "/admin", "/" (root path only), "/*", /v2/api", etc.
    6. If your application uses TLS, set
      TLS
      to
      On
      . WAAS must be able to decrypt and inspect HTTPS traffic to function properly. To facilitate that, after creating all endpoints, upload your server’s certificate and private key - concatenate public cert and private key (e.g. cat server-cert.pem server-key > certs.pem).
    7. If your application uses HTTP/2, set
      HTTP/2
      to
      On
      .
    8. Click
      Create Endpoint
    9. If your application requires API Protection, select the "API Protection" tab and define for each path allowed methods, parameters, types, etc. See detailed definition instructions in the API Protection section below.
  9. Continue to
    App Firewall
    tab, select WAAS protections to enable and assign them with WAAS Actions.
  10. Continue to
    Access Control
    tab and select WAAS Access Controls to enable.
  11. Click
    Save
    .
  12. You should be redirected to the
    Rule Overview
    page.
    Select the created new rule to display
    Rule Resources
    and for each application a list of
    protected endpoints
    and
    enabled protections
    .
  13. Test protected endpoint using the following

Deploying WAAS for hosts

To deploy WAAS to protect a host running a non-containerized web application, create a new rule, specify the host(s) where it run, define application endpoints and select protections.
  1. Open Console, and go to
    Defend > WAAS
    .
  2. Select the
    Host
    tab
  3. Click
    Add Rule
    .
  4. Enter a
    Rule Name
    and
    Notes
    (Optional) for describing the rule.
  5. Define
    Rule Resources
    .
    The rule resource section defines the hosts to which WAAS should attach itself in order to protect the web application:
    Applying a rule to all hosts using a wild card (*) is invalid and a waste of resources. WAAS only needs to be applied to hosts that run applications that transmit and receive HTTP/HTTPS traffic.
  6. Click
    Add New App
    .
  7. In the App Definition tab, specify the endpoints in your web application that should be protected. Each defined application can have multiple protected endpoints. If you have a Swagger or OpenAPI file, click Import, and select the file to load. Otherwise, skip to the next step to manually define your application’s endpoints.
  8. If you don’t have a Swagger or OpenAPI file, manually define each endpoint by specfying the host, port, and path.
    1. In the
      General App Setup
      tab, click on
      Add Endpoint
    2. Specify endpoint details:
    3. Enter
      Port (required)
      .
      Specify TCP port, in the container, listening for inbound HTTP traffic
    4. Enter
      HTTP Hostname
      (optional, wildcards supported).
      HTTP host names are specified in the form of [hostname]:[external port].
      External port is defined as the TCP port on the host, listening for inbound HTTP traffic. If the value of the external port is "80" for non-TLS endpoints or "443" for TLS endpoints it can be omitted. Examples: "*.example.site", "docs.example.site", "www.example.site:8080", etc.
    5. Enter
      Path
      (optional, wildcards supported):
      Base path for WAAS to match on when applying protections.
      Examples: "/admin/", "/" (root path only), "/*", /v2/api/", etc.
    6. If your application uses TLS, set
      TLS
      to
      On
      . WAAS must be able to decrypt and inspect HTTPS traffic to function properly. To facilitate that, after creating all endpoints, upload your server’s certificate and private key - concatenate public cert and private key (e.g. cat server-cert.pem server-key > certs.pem).
    7. If your application uses HTTP/2, set
      HTTP/2
      to
      On
      .
    8. Click
      Create Endpoint
    9. If your application requires API Protection, select the "API Protection" tab and define for each path allowed methods, parameters, types, etc. See detailed definition instructions in the API Protection section below.
  9. Continue to
    App Firewall
    tab, select WAAS protections to enable and assign them with WAAS Actions.
  10. Continue to
    Access Control
    tab and select WAAS Access Controls to enable.
  11. Click
    Save
    .
  12. You should be redirected to the
    Rule Overview
    page.
    Select the created new rule to display
    Rule Resources
    and for each application a list of
    protected endpoints
    and
    enabled protections
    .
  13. Test protected endpoint using the following

Deploying WAAS for Containers Protected By App-Embedded Defender

In some environments, Prisma Cloud Defender must be embedded directly inside the container it is protecting. This type of Defender is known as App-Embedded Defender. App-Embedded Defender can secure these types of containers with all WAAS protection capabilities.
The only difference is that App Embedded Defender runs as a reverse proxy to the container it’s protecting. As such, when you set up WAAS for App-Embedded, you must specify the exposed external port where App-Embedded Defender can listen, and the port (not exposed to the Internet) where your web application listens. WAAS for App-Embedded forwards the filtered traffic to your application’s port - unless an attack is detected and you set your WAAS for App Embedded rule to
Prevent
.
When testing your Prisma Cloud-protected container, be sure you update the security group’s inbound rules to permit TCP connections on the external port you entered in the WAAS rule. This is the exposed port that allows you to access your web application’s container. To disable WAAS protection, disable the WAAS rule, and re-expose the application’s real port by modifying the security group’s inbound rule.
To embed App-Embedded WAAS into your container or Fargate task:
  1. Open Console, and go to
    Defend > WAAS
    .
  2. Select the
    App Embedded
    tab.
  3. Click
    Add Rule
    .
  4. Enter a
    Rule Name
    and
    Notes
    (Optional) for describing the rule.
  5. Define
    Rule Resources
    .
    The rule resource section defines the App IDs to which WAAS should attach itself in order to protect the web application:
  6. Click
    Add New App
    .
  7. In the App Definition tab, specify the endpoints in your web application that should be protected. Each defined application can have multiple protected endpoints. If you have a Swagger or OpenAPI file, click Import, and select the file to load. Otherwise, skip to the next step to manually define your app’s endpoints.
  8. If you don’t have a Swagger or OpenAPI file, manually define each endpoint by specifying the host, port, and path.
    1. In the
      General App Setup
      tab, click on
      Add Endpoint
      .
    2. Specify endpoint details:
    3. Enter
      Port (required)
      Specify TCP port, in the container, listening for inbound HTTP traffic
    4. Enter
      External Port (required)
      .
      External port is the TCP port for the App-Embedded Defender to listen on for inbound HTTP traffic.
    5. Enter
      HTTP Hostname
      (optional, wildcards supported).
      HTTP host names are specified in the form of [hostname]:[external port].
      External port is defined as the TCP port on the host, listening for inbound HTTP traffic. If the the value of the external port is "80" non-TLS endpoints or "443" for TLS endpoints it can be omitted. Examples: "*.example.com", "docs.example.com", "www.example.com:8080", etc.
    6. Enter
      Path
      (optional, wildcards supported):
      Base path for WAAS to match on when applying protections.
      Examples: "/admin/", "/" (root path only), "/*", /v2/api/", etc.
    7. If your application uses TLS, set
      TLS
      to
      On
      . WAAS must be able to decrypt and inspect HTTPS traffic to function properly. To facilitate that, after creating all endpoints, upload your server’s certificate and private key - concatenate public cert and private key (e.g. cat server-cert.pem server-key > certs.pem).
    8. If your application uses HTTP/2, set
      HTTP/2
      to
      On
      .
    9. Click
      Create Endpoint
    10. If your application requires API Protection, select the "API Protection" tab and define for each path allowed methods, parameters, types, etc. See detailed definition instructions in the API Protection section below.
  9. Continue to
    App Firewall
    tab, select WAAS protections to enable and assign them with WAAS Actions.
  10. Continue to
    Access Control
    tab and select WAAS Access Controls to enable.
  11. Click
    Save
    .
  12. You should be redirected to the
    Rule Overview
    page.
    Select the new rule to display
    Rule Resources
    and for each application a list of
    protected endpoints
    and
    enabled protections
    .
  13. Test protected container using the following

Deploying WAAS for serverless functions

When Serverless Defender is embedded in a function, it offers built-in web application firewall (WAF) capabilities, including protection against:
  • SQL injection (SQLi) attacks
  • Cross-site scripting (XSS) attacks
  • Command injection (CMDi) attacks
  • Local file system inclusion (LFI) attacks
  • Code injection attacks
Some WAAS protections are not available for WAAS serverless deployment.
Prerequisites:
You already embedded Serverless Defender into your function.
  1. Open Console and go to
    Defend > WAAS > Serverless
    .
  2. Click
    Add rule
    .
  3. Enter a rule name.
  4. Select
    Alert
    or
    Prevent
    .
  5. Select the protections to enable.
  6. Enter the functions to protect.
    Use pattern matching to precisely target your rule.

WAAS Actions

HTTP requests that trigger WAAS protections are subject to one of the following actions:
  • Alert
    - Request is passed to the protected application and an audit is generated for visibility.
  • Prevent
    - Request is denied from reaching the protected application, an audit is generated and WAAS responds with an HTML banner indicating the request was blocked.
  • Ban
    - All requests originating from the same IP address to the protected application are denied for a time period of 5 minutes since the last detected attack (Penalty Box).
WAAS implements state, which is required for banning user sessions by IP address. Because Defenders do not share state, any application that is replicated across multiple nodes must enable IP address stickiness on the load balancer.

WAAS protections

OWASP Top 10 protection

WAAS offers protection for the critical security risks described in the OWASP Top Ten list.

SQL injection

An SQL injection (SQLi) attack occurs when an attacker inserts an SQL query into the input fields of a web application. A successful attack can read sensitive data from the database, modify data in the database, or run arbitrary commands.
WAAS parses and tokenizes input streams (request data) and then detects malicious attempts to inject unauthorized SQL queries.

Cross Site Scripting

Cross-Site Scripting (XSS) is a type of injection attack, in which malicious JavaScript snippets are injected into otherwise benign and trusted web sites. Attackers try to trick the browser into switching to a Javascript context, and executing arbitrary code.
WAAS parses and tokenizes input streams (request data) and then searches for matching fingerprints of known malicious attack patterns.

Command & Code Injection

Command injection is a form of attack in which attackers attempt to run arbitrary commands on the web application’s host. Code injection is a form of attack in which code is injected and interpreted by the application or other runtimes. Command and code payloads are either injected as part of HTTP requests or included from local or remote files (also known as File Inclusion).
WAAS inspects all HTTP requests sent to the application and protects against all types of injection attacks as well as local file inclusions.
Prisma Cloud architecture facilitates defense in-depth via multiple protection layers. Enabling Runtime Protection in addition to WAAS would allow profiling of the application and identifying any anomalies resulting from command or code injections (e.g. unexpected new processes or DNS queries)

Local File Inclusion

Local File Inclusion is a form of attack in which attackers attempt to gain unauthorized access to locally stored sensitive files on the web application host. Such access attempts are often made using directory traversal attacks or exploiting file inclusion vulnerabilities in the application.
WAAS inspects all HTTP requests sent to the application for local file inclusion attacks aiming at sensitive system files as well as other various traversal attempts.

Attack Tool & Vulnerability Scanners

Vulnerability scanners are automated tools that scan web applications for known security vulnerabilities and misconfiguration.
Web crawlers are automated tools designed to systematically access and enumerate the content of web applications. Crawling can lead to data breaches by exposing resources that should not be publicly available, or revealing opportunities for hacking by exposing software versions, environment data, and so on.
WAAS is continuously updated with new signatures of widely used web attack arsenal, crawlers and penetration testing tools.

API Protection

WAAS is able to enforce API security based on specifications provided in the form of Swagger or OpenAPI files. WAAS also allows for manual API definition. E.g. paths, allowed HTTP methods, parameter names, input types, value ranges, etc. Once defined, users can choose WAAS actions to apply for requests which do not comply with the API’s expected behavior.

Importing API Definition From Swagger or OpenAPI

  1. Enter
    App Definiton
    Tab.
  2. Click on
    Import
    .
  3. Select definition file to load.
  4. Select
    API Protection
    Tab.
  5. Review path and parameter definitions
    Base path in the endpoint definition should always end with a * e.g. "/*", "/api/v2/*". If not configured that way, API protection will not apply to sub-paths defined in the API protection tab.
  6. Enter
    App Firewall
    Tab.
  7. Assign
    API Protection
    protection relevant action.

Manual API Definition

  1. Enter
    App Definiton
    Tab.
  2. Click
    Add Endpoint
    and enter API HTTP hostnames and base paths.
Base path in the endpoint definition should always end with a * e.g. "/*", "/api/v2/*". If not configured that way, API protection would not apply to sub-paths defined in the API protection tab.
  1. Select
    API Protection
    Tab.
  2. Click
    Add Path
  3. Enter
    Resource Path
    (e.g. /product - resource paths should not end with a trailing "/")
    Paths entered in this section are additional subpaths to the base path defined in the previous endpoint section. for example, if in the endpoint definition hostname was set to "www.example.com", base path set to "/api/v2/*" and in the
    API Protection
    tab resource path set to "/product" - full protected resource would be www.example.com/api/v2/product.
  4. Select allowed
    HTTP Methods
    .
  5. For each allowed HTTP method, define parameters by selecting the method from
    Parameters for
    dropdown list.
  6. For each HTTP method add allowed parameters:
    1. Click
      Add Parameter
    2. Enter parameter definition
  7. Enter
    App Firewall
    Tab
  8. Assign
    API Protection
    protection relvant action
To apply actions on requests that do not include mandatory parameters, make sure to set the
Required
toggle switch to
On
for all mandatory parameters.

Security Misconfigurations

Shellshock

Shellshock is a unique privilege escalation vulnerability that permits remote code execution. In unpatched versions of the bash shell interpreter, the Shellshock vulnerability lets attackers create environment variables with specially crafted values that contain code. As soon as the shell is invoked, the attacker’s code is executed.
WAAS checks for requests that are crafted to exploit the Shellshock vulnerability.
For more information about Shellshock, see CVE-2014-6271.

Malformed Request Protection

WAAS validates the structure of HTTP requests, automatically blocking those that are malformed.
Examples of malformed requests include:
  • HTTP GET requests with a body.
  • HTTP POST requests without a Content-Length header.

Cross-site Request Forgery

Cross-site request forgery (CSRF) attacks trick the victim’s browser into executing unwanted actions on a web application in which the victim is currently authenticated. WAAS mitigates CSRF attacks by intercepting responses and setting the 'SameSite' cookie attribute value to 'strict'. The 'SameSite' attribute prevents browsers from sending the cookie along with cross-site requests. It only permits the cookie to be sent along with same-site requests.
There are several techniques for mitigating CSRF, including synchronizer (anti-CSRF) tokens, which developers must implement as part of your web application. The synchronizer token pattern generates random challenge tokens associated with a user’s session. These tokens are inserted into forms as a hidden field, to be submitted along with your forms. If the server cannot validate the token, the server rejects the requested action.
The SameSite cookie attribute works as a complementary defense against CSRF, and helps mitigate against things such as faulty implementation of the synchronizer token pattern.
  • When the SameSite attribute is not set, the cookie is always sent.
  • With SameSite attribute set to strict, the cookie is never sent in cross-site requests.
  • With SameSite attribute set to lax, the cookie is only sent on same-site requests or top-level navigation with a safe HTTP method, such as GET.
It is not sent with cross-domain POST requests or when loading the site in a cross-origin frame. It is sent when you navigate to a site by clicking on a <a href=…​> link that changes the URL in your browser’s address bar.
  • Chrome 61 or later.
  • Firefox 58 or later.
For more information about the SameSite attribute, see https://tools.ietf.org/html/draft-west-first-party-cookies-07

Clickjacking

Web applications that permit their content to be embedded in a frame are at risk of clickjacking attacks. Attackers can exploit permissive settings to invisibly load the target website into their own site and trick users into clicking on links which they never intended to click.
WAAS modifies all response headers, setting the X-Frame-Options response header value to SAMEORIGIN. The SAMEORIGIN directive only permits a page to be displayed in a frame on the same origin as the page itself.

Intelligence Gathering

Error messages give attackers insight into the inner workings of your application. It is therefore important to prevent information leakage.
The following controls limit the exposure of sensitive information.

Brute Force Protection

WAAS limits the number of POST requests per minute, per IP. If a threshold of more than thirty POST requests is exceeded in a short interval, the source IP address is banned for 5 minutes.
The brute force protection threshold is fixed and cannot be changed by users. This prevents attackers from guessing passwords and flooding your application with unnecessary traffic.
WAAS implements state, which is required for banning user sessions by IP address. Because Defenders do not share state, any application that is replicated across multiple nodes must enable IP stickiness on the load balancer.
"Brute-Force Protection" and "Track Response Error Codes" protections share the same count of 30 requests per minute, per IP, per policy. For example, an IP address accessing endpoints protected under the same policy, would get banned for 5 minutes when sending 20 POST requests and receiving 10 error responses from the server, as it would effectively meet the block threshold (20 POST + 10 errors = 30).

Track Response Error Codes

Many failures in rapid succession can indicate that an automated attack is underway. WAAS applies rate-based rules to mitigate these types of attacks. Any HTTP response with a status code equal or greater than 400 is considered as a failure and would be included in the error rate counting. If a threshold of more than thirty errors per minute, per IP address is exceeded, the source IP address is blocked for 5 minutes. The response error codes rate threshold is fixed and cannot be changed by users. If an attacker tries to access non-existing URLs that are known administration pages for various web application frameworks, the source IP address will be immediately blocked for 5 minutes.
WAAS implements state, which is required for banning user sessions by IP address. Because Defenders do not share state, any application that is replicated across multiple nodes must enable IP stickiness on the load balancer.
"Brute-Force Protection" and "Track Response Error Codes" Protection share the same count of 30 requests per minute, per IP, per policy. For example, an IP address accessing endpoints protected under the same policy, would get banned for 5 minutes when sending 20 POST requests and receiving 10 error responses from the server, as it would effectively meet the block threshold (20 POST + 10 errors = 30).

Remove Server Fingerprints

By gathering information about the software type and version used by the web application, attackers may learn about potentially known weaknesses and bugs and exploit them.
Eliminating unnecessary headers makes it more difficult for attackers to identify the frameworks that underpin your application.
Response headers that advertise your application’s web server and other server details should be scrubbed. WAAS automatically removes unnecessary headers, such as X-Powered-By, Server, X-AspNet-Version, and X-AspNetMvc-Version.

Detect Information Leakage

WAAS detects situations where the contents of critical files, such as /etc/shadow, /etc/passwd, and private keys, are contained in responses. WAAS will also detect when responses contain directory listings, output from php_info() function calls, and other similar data leakage cases of potentially risky information.

WAAS Access Controls

WAAS allows for control over how applications and end-users communicate with the protected web application.

Network Lists

Network Lists
allow administrators to create and maintain named IP address lists e.g. "Office Branches", "Tor and VPN Exit Nodes", "Business Partners", etc. List entries are composed of IPv4 addresses or IP CIDR blocks.
To access
Network Lists
, open Console, go to
Defend > WAAS
and select the
Network List
tab.
Lists can be updated manually or via batch importing of entries from a CSV file. Once defined,
Network Lists
can be referenced and used in IP-based access control.
To export lists in CSV format, click
export CSV
.
When importing IP addresses or IP CIDR blocks from a CSV file, first record value should be set to "ip" (case sensitive).
IPv6 entries are currently not supported.

Network Controls

IP-based access control

Network lists can be specified in:
  • - WAAS applies selected action (Alert or Prevent) for IP addresses in network lists.
  • - Traffic originating from IP addresses listed in this category will not be inspected by any of the protections defined in this policy.
We strongly advise users to practice caution when adding network lists to the IP Exception List as protections will not be applied for traffic originating from these IP addresses.

Country-Based Access Control

Specify country codes, ISO 3166-1 alpha-2 format, in one of the following categories (mutually exclusive):
  • - WAAS applies selected action (Alert or Prevent) for requests originating from the specified countries.
  • - Requests originating from specified countries will be forwarded to the application (pending inspection). WAAS will apply action of choice (Alert or Prevent) on all other requests not originating from the specified countries.
Country of origin is determined by the IP address associated with the request.

HTTP Header Controls

WAAS lets you block or allow requests which contain specific strings in HTTP headers by specifying a header name and a value to match. The value can be a full or partial string match. Standard pattern matching is supported.
If the
Required
toggle is set to
On
WAAS will apply the defined action on HTTP requests in which the specified HTTP header is missing. When the
Required
toggle is set to
Off
no action will be applied for HTTP requests missing the specified HTTP header.
HTTP Header fields consist of a name, followed by a colon, and then the field value. When decoding field values, WAAS treats all commas as delimiters. For example, the Accept-Encoding request header advertises which compression algorithm the client supports.
Accept-Encoding: gzip, deflate, br
WAAS rules do not support exact matching when the value in a multi-value string contains a comma because WAAS treats all commas as delimiters. To match this type of value, use wildcards. For example, consider the following header:
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.108 Safari/537.36
To match it, specify the following wildcard expression in your WAAS rule:
Mozilla/5.0*

File Upload Controls

Attackers may try to upload malicious files (e.g. malware) to your systems. WAAS protects your applications against malware dropping by restricting uploads to just the files that match any allowed content types. All other files will be blocked.
Files are validated both by their extension and their magic numbers. Built-in support is provided for the following file types:
  • Audio: aac, mp3, wav.
  • Compressed archives: 7zip, gzip, rar, zip.
  • Documents: odf, pdf, Microsoft Office (legacy, Ooxml).
  • Images: bmp, gif, ico, jpeg, png.
  • Video: avi, mp4.
WAAS rules let you explicitly allow additional file extensions. These lists provide a mechanism to extend support to file types with no built-in support, and as a fallback in case Prisma Cloud’s built-in inspectors fail to correctly identify a file of a given type. Any file with an allowed extension is automatically permitted through the firewall, regardless of its 'magic number'.

cURL Test Commands

Below are curl-based tests that can be used to verify endpoints have been properly defined. Make sure all changes are saved prior to running these tests. The method for verifying test results differs according to the selected action:
  • Alert
    - Go to
    Monitor > Events
    to see alerts logged by Prisma Cloud relating to this policy violation.
  • Prevent
    - Commands return output similar to the following:
    HTTP/1.1 403 Forbidden Date: Wed, 15 Jul 2020 12:51:50 GMT Content-Type: text/html; charset=utf-8
In the following examples, replace <http_hostname> with your endpoint’s hostname and <external_port> with the web facing port of your application. For testing HTTP header access control, also replace <http_header_name> with the header name set in the rule and <http_header_value> with set values.
SQL injection:
curl -I http://<http_hostname>:<external_port>/\?id\=%27%20OR%20%271
Cross-site scripting:
curl -I http://<http_hostname>:<external_port>/\?id\=\<script\>alert\(\1\)\>/script\>
OS command injection:
curl -I http://<http_hostname>:<external_port>/\?id\=/bin/sh/
Code injection:
curl -I http://<http_hostname>:<external_port>/\?id\=phpinfo()
Local file inclusion:
curl -I http://<http_hostname>:<external_port>/\?id\=../etc/passwd
Attack tools and vulnerability scanners:
curl -I -H 'User-Agent: sqlmap' http://<http_hostname>:<external_port>/
Shellshock protection:
curl -I -H "User-Agent: () { :; }; /bin/eject" http://<http_hostname>:<external_port>/
Malformed HTTP request:
curl -s -i -X GET -o /dev/null -D - -d '{"test":"test"}' http://<http_hostname>:<external_port>/
HTTP header access controls:
curl -H '<header_Name>: <header_value>' http://<http_hostname>:<external_port>/

Recommended For You