Web-Application and API Security (WAAS)
WAAS (Web-Application and API Security, formerly known as CNAF, Cloud Native Application Firewall) is a web application firewall (WAF) designed for HTTP-based web applications deployed directly on hosts, as containers, application embedded or serverless functions.
WAFs secure web applications by inspecting and filtering layer 7 traffic to and from the application.
WAAS enhances the traditional WAF protection model by deploying closer to the application, easily scaling up or down and allowing for inspection of "internal" traffic (east-to-west) from other micro-services as well as inbound traffic (north-to-south).
For containerized web applications, WAAS binds to the application’s running containers, regardless of the cloud, orchestrator, node, or IP address where it runs, and without the need to configure any complicated routing.
For non-containerized web applications, WAAS simply binds to the host where the application runs.
Highlights of WAAS’s capabilities:
- OWASP Top-10 Coverage- protection against most critical security risks to web applications, including injection flaws, broken authentication, broken access control, security misconfigurations, etc.
- Access Control- WAAS controls access to protected applications using Geo-based, IP-based or HTTP Header-based user defined restrictions.
- File Upload Control- WAAS secures application file uploads by enforcing file extension rules.
- Detection of Unprotected Web Applications- WAAS detects unprotected web applications and flags them in the radar view.
- Penalty Box for Attackers- WAAS supports a 5 minutes ban of IPs triggering one of it’s protections to slow down vulnerability scanners and other attackers probing the application.
Architecture
WAAS is deployed via Prisma Compute Defenders which operate as a transparent HTTP proxy, evaluating client requests against security policies before relaying the requests to your application.
Defenders are deployed into the environment in which the web applications run.
WAAS’s management console is independent of the Defenders and can be self-hosted or provided as a service (SaaS):
When a firewall is deployed, Defender reroutes traffic bound for your web application to WAAS for inspection.
If a connection is secured with TLS, Defender decrypts the traffic, examines the content, and then re-encrypts it.
Legitimate requests are passed to the target container or host.
Requests triggering one or more WAAS protections generate a WAAS "event audit" and an action is taken based on the preconfigured action (see "WAAS Actions" below).
WAAS’s event audits can be further explored in the "Monitor" section of Prisma Compute’s management console (
Monitor > Events
).
In addition, event audits are registered in the Defender’s syslog thus allowing for integration with third-party analytics engines or SIEM platforms of choice.WAAS Actions
Requests that trigger a WAAS protection are subject to one of the following actions:
- Alert- The request is passed to the protected application and an audit is generated for visibility.
- Prevent- The request is denied from reaching the protected application, an audit is generated and WAAS responds with an HTML page indicating the request was blocked.
- Ban- All requests originating from the same IP to the protected application are denied for a time period of 5 minutes following 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 stickiness on the load balancer.
Operation
Deploying WAAS
WAAS is enabled by adding a new WAAS rule.
Whenever new policies are created, or existing policies are updated, Prisma Cloud immediately pushes them to all the resources to which they apply.
To deploy WAAS, create a new WAAS rule, select the resources on which to apply the rule, define your web application and select the protections to enable.
For containerized web applications, Prisma Cloud creates a firewall instance for each container instance.
For legacy (non-containerized web applications), Prisma Cloud creates a firewall for each host specified in the configuration.
For detailed information see our step-by-step deployment guide.
Prisma Cloud can also protect Fargate-based web containers.
See WAAS for Fargate.
Supported Protocols, Message Parsers and Decoders
Supported Protocols
- HTTP 1.0, 1.1, 2.0 - full support of all HTTP methods
- TLS 1.0, 1.1, 1.2, 1.3
- WebSockets Passthrough
Supported Message Parsers and Decoders
- GZip, deflate content encoding
- HTTP Multipart content type
- URL Query, x-www-form-urlencoded, JSON and XML parameter parsing
- URL, HTML Entity, JS, BASE64 decoding
- Overlong UTF-8
Protection Capabilities
WAAS provides a rich set of capabilities to protect your web application from attacks.
Detection of Unprotected Web Applications
Once a day, the Defender scans its environment for unprotected web applications and marks them on the radar view.
OWASP Top-10 Protection
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 (see more on Local File Inclusion below).
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.
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.
Currently, the
following browsers support the SameSite attribute:
- 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.
Access Control
WAAS can control which applications and end-users can communicate with the protected web application.
IP-based Access Control
Administrators can create user-defined Network IP lists and name them e.g. "Office Branches", "Tor and VPN exit nodes", "Business Partners", etc.
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 would not apply for traffic originating from those IP addresses.
Country-based Access Control
Country codes can be specified in:
- - WAAS applies selected action (Alert or Prevent) for requests originating from the specified country.
- - Requests originating from specified countries would be forwarded to the application (pending inspection). WAAS will apply action of choice (Alert or Prevent) for all other requests not originating from specified countries.
Origin country is determined by the IP address associated with the request.
HTTP Header-based Access Control
WAAS lets you block or allow requests that contain specific values in HTTP headers.
Specify a header and a value to match. The value can be a full or partial string match.
Standard pattern matching is supported.
Pattern matching for this value is same as throughout the product.
Header fields consist of a name, followed by a colon, and then the field value.
When decoding field values, WAAS treats 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 Uploads
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'.
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.
Most Popular
