NGINX Documentation

Configuration Guide

Overview

This guide explains the NGINX App Protect security features and how to use them.

Supported Default Security Policy Features

The following security features are supported by the default NGINX App Protect policy.

Evasion Techniques

These evasion techniques provide OWASP Top 10 Application Security protection.

Protection Mechanism Description
Disallow DTD XML content profile Support all XML profile checks except for: SOAP; Web Services Security options; xsd; illegal meta chars; sensitive data; excluded sigs
Parameter parsing Support only auto-detect parameter value type. (default, cannot be changed in config). Support both WC/explicit param name.
Disallow file type extension Support any file type. Default includes a predefined list of file types. See Disallowed File Types list below.
Disallowed meta characters in parameters Both name and value
HttpOnly, Secure cookie attribute enforcement Support both allowed and enforced cookies. Support both WC/explicit cookie name.
Signature attack for Server Technologies Support adding signatures per added server technology.
Sensitive Parameters Mask the password in the security log.
Character/Metacharacter validation​ in URL and in header Support specifying character set per type (param/url/header) and not per entity (param name).
JSON parameterization JSON profile will support the following fields: Maximum Total Length Of JSON Data; maximum value length; max structure depth; max array len; tolerate json parsing errors. JSON parameterization and schema enforcement is not supported.
Allowed methods Check HTTP allowed methods.
Black & White IP listing Manually define black & white IP addresses.
Trust XFF header List of alternate Headers. Disabled by default

Disallowed File Types

The following file types are disallowed by default:

  • bak, bat, bck, bkp, cfg, conf, config, ini, log, old, sav, save, temp, tmp
  • bin, cgi, cmd, com, dll, exe, msi, sys, shtm, shtml, stm
  • cer, crt, der, key, p12, p7b, p7c, pem, pfx
  • dat, eml, hta, htr, htw, ida, idc, idq, nws, pol, printer, reg, wmz

Additional Techniques

Protection Mechanism Description
Bad unescape (bad escaping); Directory Traversal; Bare byte decoding; Apache Whitespace; Multiple % decoding; IIS Unicode codepoint; IIS backslashes; %u decoding Support disabling every one of the sub-violations in the declarative configuration. Support specifying max decode iterations.
Malformed cookie; Illegal status code (i.e. 400s besides 404); Request size exceeds the buffer; Size checks for: URL, header, Query String, whole request, cookie, POST data Support all size limitations available in JSON and XML profiles. By default, check only the nesting level.
HTTP Compliance All checks enabled by default except for GET with body and POST without body.
Support customization of blocking page Supported.
Data Guard Credit card and US Social Security numbers blocked by default.

Configuring Attack Signatures

App Protect includes predefined attack signatures to protect your application against all attack types identified by the system. As new attack signatures are identified, they will become available for download so that your system will always have the most up-to-date protection. You can update the attack signatures without updating the App Protect release, and conversely, you can update App Protect without changing the attack signature package, unless you moved to a new NGINX Plus release.

Signature Settings

Setting JSON Property in Policy Support in NGINX App Protect Value in Default Profile
Signature Sets signature-sets All available sets.  
Signatures signatures “Enabled” flag can be modified. All signatures in the included sets are enabled.
Enable Signature Staging signature-settings.signatureStaging Locked to false (disabled). May not be modified. False
Updated Signature Enforcement signature-settings.placeSignaturesInStaging Locked. N/A
Auto-Added signature accuracy minimumAccuracyForAutoAddedSignatures Editable Low
Attack Signature False Positive Mode attackSignatureFalsePositiveMode Editable detect-and-allow

Signature Sets in Default Template

The following signature sets are included in the default template. All are set with the Alarm flag enabled and Block disabled except High Accuracy Signatures, which are set to blocked.

Signature Set Name Type Comment
Command Execution Signatures Attack Type Specific  
Cross Site Scripting Signatures Attack Type Specific  
Directory Indexing Signatures Attack Type Specific  
Information Leakage Signatures Attack Type Specific  
OS Command Injection Signatures Attack Type Specific  
Path Traversal Signatures Attack Type Specific  
Predictable Resource Location Signatures Attack Type Specific  
Remote File Include Signatures Attack Type Specific  
SQL Injection Signatures Attack Type Specific  
Authentication/Authorization Attacks Signatures Attack Type Specific  
XML External Entity (XXE) Signatures Attack Type Specific  
XPath Injection Signatures Attack Type Specific  
Buffer Overflow Signatures Attack Type Specific  
Denial of Service Signatures Attack Type Specific  
Vulnerability Scanner Signatures Attack Type Specific  
High Accuracy    
All CVE    

Basic Signature Sets Included in App Protect

These signatures sets are included but are not part of the default template.

  • All Response Signatures
  • All Signatures
  • Generic Detection Signatures
  • Generic Detection Signatures (High Accuracy)
  • Generic Detection Signatures (High/Medium Accuracy)
  • High Accuracy Signatures
  • Low Accuracy Signatures
  • Medium Accuracy Signatures
  • OWA Signatures
  • WebSphere signatures

Attack Type Specific Signature Sets Included in App Protect

  • Command Execution Signatures
  • Cross Site Scripting Signatures
  • Directory Indexing Signatures
  • HTTP Response Splitting Signatures
  • High Accuracy Detection Evasion Signatures
  • Information Leakage Signatures
  • OS Command Injection Signatures
  • Other Application Attacks Signatures
  • Path Traversal Signatures
  • Predictable Resource Location Signatures
  • Remote File Include Signatures
  • SQL Injection Signatures
  • Server Side Code Injection Signatures
  • Server-Side Request Forgery Signatures
  • Server-Side Request Forgery Signatures (High Accuracy)
  • Server-Side Request Forgery Signatures (High/Medium Accuracy)
  • XPath Injection Signatures

Policy Configuration

The NGINX App Protect default base template provides a default configuration that provides the OWASP Top 10 security protection out of the box.

Overview

The NGINX App Protect security policy configuration uses the declarative format. The declarative interface enables making dynamic changes to add and remove security capabilities to the security policy. Security Policy changes can be done in the modification without the need to configure the whole policy by renaming the items of the changes or by removing them, while the rest of the policy configuration will be left intact.

The way the policy is integrated into the NGINX configuration is via referencing the json file (using the full path) in the nginx.conf file.

In the following example, the NGINX configuration file with App Protect enabled in the HTTP context and the policy /etc/nginx/NginxDefaultPolicy.json is used:

user nginx;
worker_processes  4;
 
load_module modules/ngx_http_app_protect_module.so;
 
error_log /var/log/nginx/error.log debug;
working_directory /tmp/cores;
worker_rlimit_core 1000M;
 
events {
    worker_connections  65536;
}
 
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
 
    app_protect_enable on; # This is how you enable NGINX App Protect in the relevant context/block
    app_protect_policy_file "/etc/nginx/NginxDefaultPolicy.json"; # This is a reference to the policy file to use. If not defined, the default policy is used
    app_protect_security_log_enable on; # This section enables the logging capability (remote logging only)
    app_protect_security_log "/etc/nginx/log-default.json" syslog:server=127.0.0.1:515; # This is where the remote logger is defined in terms of: logging options (defined in the referenced file), log server IP, log server port
 
    server {
        listen       80;
        server_name  localhost;
        proxy_http_version 1.1;
 
        location / {
            client_max_body_size 0;
            default_type text/html;
            proxy_pass http://172.29.38.211:80$request_uri;
        }
    }
}

Basic Configuration

The default basic template configuration deals with setting actions that will be effective throughout the whole policy, namely, the general behavior and enforcement of the policy.

The default policy enforces violations by Violation Rating, the App Protect computed assessment of the risk of the request based on the triggered violations.

  • 0: No violation
  • 1-2: False positive
  • 3: Needs examination
  • 4-5: Threat

The default policy enables most of the violations with Alarm turned on, but not Block. By default, if the violation rating is 4-5 the request is blocked using the VIOL_RATING_THREAT violation. By default, all other requests are not blocked. This is to minimize false positives. However, you can change the default behavior. For example, if you want to add blocking on a violation rating of 3 as well, enable blocking for the VIOL_RATING_NEED_EXAMINATION violation. The High Accuracy signatures that block a request regardless of its Violation Rating are an exception to this.

Policy Enforcement Modes

A policy’s enforcement mode can be:

  • Blocking: Any illegal or suspicious requests are logged and blocked.
  • Transparent: Any illegal or suspicious requests are logged but not blocked.

Specific security features can be defined as blocked or transparent in the policy.

Blocking Mode example:

{
    "policy": {
        "name": "policy_name",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking"
    }
}

Transparent Mode example:

{
    "policy": {
        "name": "policy_name",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "transparent"
    }
}

Enabling Violations

Adding and enabling additional security features to the policy can be done by specifying the violation name and the alarm block state to “true”. To set different states to sub-violations within the violation, enable the violation first, then specifying and enable the sub-violations. Also, a violation may have its own section that provides additional configuration granularity for a specific violation/sub-violation. The examples below show how to enable a violation and sub-violation in a declarative format.

Configuration details example:

In this example, we enable 2 violations: VIOL_JSON_FORMAT and VIOL_PARAMETER_VALUE_METACHAR.

Note that the example defines the blocking and alarm setting for each violation. These settings override the default configuration set above in the enforcementMode directive. Be aware, however, that in a transparent policy no violations are blocked, even if specific violations are set to block: true in the configuration.

{
   "policy": {
       "name": "policy_name",
       "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
       "applicationLanguage": "utf-8",
       "enforcementMode": "blocking",
       "blocking-settings": {
           "violations": [
               {
                   "name": "VIOL_JSON_FORMAT",
                   "alarm": true,
                   "block": true
               },
               {
                   "name": "VIOL_PARAMETER_VALUE_METACHAR",
                   "alarm": false,
                   "block": false
               }
           ]
       }
   }
}

HTTP Compliance

HTTP compliance is one of the basic application security violations. It validates the request itself and also prevents the use of the HTTP protocol as an entry point to the application.

In this example, we enable the HTTP compliance violation with the blocking as true. We also configure (enabled or disabled) all of its sub-violations in the relevant HTTP section. Note that you can add/remove sub-violations to match your desired configurations. However, not listing a violation does not mean it will be disabled. Rather, it would actually mean that the default configuration would not be overridden for that specific sub-violation.

{
    "policy": {
        "name": "policy_name",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_HTTP_PROTOCOL",
                    "alarm": true,
                    "block": true
                }
            ],
            "http-protocols": [
                {
                    "description": "Bad host header value",
                    "enabled": true
                },
                {
                    "description": "Bad HTTP version",
                    "enabled": true
                },
                {
                    "description": "Content length should be a positive number",
                    "enabled": true
                },
                {
                    "description": "No Host header in HTTP/1.1 request",
                    "enabled": true
                },
                {
                    "description": "Null in request",
                    "enabled": true
                },
                {
                    "description": "Several Content-Length headers",
                    "enabled": true
                },
                {
                    "description": "Unparsable request content",
                    "enabled": true
                }
            ]
        }
    }
}

Evasion Techniques

Evasion techniques refers to techniques usually used by hackers to attempt to access resources or evade what would otherwise be identified as an attack. Like HTTP compliance, evasion techniques have a list of sub-violations that can be configured for additional granularity and to reduce false positives.

In this example, we enable the evasion technique violation with the blocking as true. We also configure (enabled or disabled) all of its sub-violations in the relevant section. Note that you can add/remove sub-violations to match your desired configurations. However, not listing a violation does not mean it will be disabled. Rather, it would actually mean that the default configuration would not be overridden for that specific sub-violation.

{
    "policy": {
        "name": "evasions_enabled",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_EVASION",
                    "alarm": true,
                    "block": true
                }
            ],
            "evasions": [
                {
                    "description": "Bad unescape",
                    "enabled": true,
                    "learn": false
                },
                {
                    "description": "Directory traversals",
                    "enabled": true,
                    "learn": false
                },
                {
                    "description": "Bare byte decoding",
                    "enabled": true,
                    "learn": false
                },
                {
                    "description": "Apache whitespace",
                    "enabled": true,
                    "learn": false
                },
                {
                    "description": "Multiple decoding",
                    "enabled": true,
                    "learn": false,
                    "maxDecodingPasses": 2
                },
                {
                    "description": "IIS Unicode codepoints",
                    "enabled": true,
                    "learn": false
                },
                {
                    "description": "IIS backslashes",
                    "enabled": true,
                    "learn": false
                },
                {
                    "description": "%u decoding",
                    "enabled": true,
                    "learn": false
                }
            ]
        }
    }
}

Attack Signatures

Attack signatures may be a little more difficult to configure as there are a number of configuration items and values in different places that may seem confusing. The first thing to be done is to enable the attack signature violation itself. Then, we need to configure which signature sets are to be enforced. Note that there are different ways to configure these sets and that there might be some overlap when doing so. You can also enable/disable signatures individually (but that would be a very exhaustive process).

In this example, we enable the attack signature violation, and specify that we want to enforce all signatures. Note that blocking setting cannot be blank.

{
    "policy": {
        "name": "attack_sigs",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "signature-sets": [
            {
                "name": "All Signatures",
                "block": true,
                "alarm": true
            }
        ]
    }
}

In this example, we enable the attack signature violation, and specify that we want to enforce only high accuracy signatures.

{
    "policy": {
        "name": "attack_sigs",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "signature-sets": [
            {
                "name": "High Accuracy Signatures",
                "block": true,
                "alarm": true
            }
        ]
    }
}

In this example, we exclude the signature ID 200001834.

{
    "policy": {
        "name": "signature_exclude",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "signature-sets": [
            {
                "name": "All Signatures",
                "block": true,
                "alarm": true,
                "learn": false
            }
        ],
        "signatures": [
            {
                "signatureId": 200001834,
                "enabled": false                
            }
        ]
    }
}

In this example, the policy is the same but a new section is added and the attack signatures to be modified are appended. We use the same signature ID 200001834:

{
    "policy": {
        "name": "signature_modification_entitytype",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "signature-sets": [
            {
                "name": "All Signatures",
                "block": true,
                "alarm": true,
                "learn": false
            }
        ]
    },
    "modifications": [
        {
            "entityChanges": {
                "enabled": false
            },
            "entity": {
                "signatureId": 200001834
            },
            "entityType": "signature",
            "action": "add-or-update"
        }
    ]
}

For multiple attack signatures, the signature IDs need to be added as separate entities under the modification list, each on its own, with only the signature ID updated:

"modifications": [
    {
        "entityChanges": {
            "enabled": false
        },
        "entity": {
            "signatureId": 200001834
        },
        "entityType": "signature",
        "action": "add-or-update"
    },
    {
        "entityChanges": {
            "enabled": false
        },
        "entity": {
            "signatureId": 200004461
        },
        "entityType": "signature",
        "action": "add-or-update"
    }
]

Server Technologies

Another way to configure attack signature sets is by applying server technologies. Server technologies applies sets of signatures that would be relevant to attacks targeted to a specific OS, application, or server type.

In this example, we enable the attack signature violation, and enabled the Apache/NCSA HTTP Server server technology, which in tern enables attack signatures specific to this type of technology. We also enabled signatures with minimum accuracy of low. This would include low, medium, and high accuracy attack signatures.

{
    "policy": {
        "name": "policy_name",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "signature-settings": {
            "placeSignaturesInStaging": false,
            "attackSignatureFalsePositiveMode": "disabled",
            "minimumAccuracyForAutoAddedSignatures": "low"
        },
        "server-technologies": [
            { "serverTechnologyName": "Apache/NCSA HTTP Server" }
        ]
    }
}
Available Server Technologies

The table below lists all the available Server Technologies. Some of them are built on top others on the stack and including them implies the inclusion of the latter. For example: ASP.NET implies both IIS and Microsoft Windows.

Server Technology Name Description Implied Technologies
Jenkins Jenkins is an open source automation server written in Java. Jenkins helps to automate the non-human part of the software development process, with continuous integration and facilitating technical aspects of continuous delivery. It is a server-based system that runs in servlet containers such as Apache Tomcat.  
SharePoint SharePoint is a web-based collaborative platform that integrates with Microsoft Office. Launched in 2001, SharePoint is primarily sold as a document management and storage system, but the product is highly configurable and usage varies substantially among organizations.  
Oracle Application Server Oracle Internet Application Server provides a single integrated packaged solution of for middleware infrastructure including Oracle Containers for J2EE, Oracle Web Cache, Oracle HTTP Server, Oracle Forms, Oracle Reports, Oracle Portal and Oracle Discoverer.  
Python Python is an interpreted, high-level, general-purpose programming language. Created by Guido van Rossum and first released in 1991, Python has a design philosophy that emphasizes code readability, notably using significant whitespace. It provides constructs that enable clear programming on both small and large scales.  
Oracle Identity Manager Oracle Identity Manager (OIM) enables enterprises to manage the entire user life-cycle across all enterprise resources both within and beyond a firewall. Within Oracle Identity Management it provides a mechanism for implementing the user-management aspects of a corporate policy.  
Spring Boot Spring Boot makes it easy to create Spring-powered, production-grade applications and services with absolute minimum fuss. It takes an opinionated view of the Spring platform so that new and existing users can quickly get to the bits they need.  
CouchDB Apache CouchDB is open source database software that focuses on ease of use and having a scalable architecture.  
SQLite SQLite is a relational database management system contained in a C programming library. In contrast to many other database management systems, SQLite is not a client-server database engine. Rather, it is embedded into the end program.  
Handlebars Handlebars provides the power necessary to let you build semantic templates effectively with no frustration.  
Mustache Mustache is a simple web template system.  
Prototype Prototype takes the complexity out of client-side web programming. Built to solve real-world problems, it adds useful extensions to the browser scripting environment and provides elegant APIs around the clumsy interfaces of Ajax and the Document Object Model.  
Zend Zend Server is a complete and certified PHP distribution stack fully maintained and supported by Zend Technologies. It ships with an updated set of advanced value-add features designed to optimize productivity, performance, scalability and reliability.  
Redis Redis is an open-source in-memory data structure project implementing a distributed, in-memory key-value database with optional durability. Redis supports different kinds of abstract data structures, such as strings, lists, maps, sets, sorted sets, hyperloglogs, bitmaps, streams and spatial indexes.  
Underscore.js Underscore.js is a JavaScript library which provides utility functions for common programming tasks. It is comparable to features provided by Prototype.js and the Ruby language, but opts for a functional programming design instead of extending object prototypes  
Ember.js Ember.js is an open-source JavaScript web framework, based on the Model-view-viewmodel pattern. It allows developers to create scalable single-page web applications by incorporating common idioms and best practices into the framework.  
ZURB Foundation Foundation is a responsive front-end framework. Foundation provides a responsive grid and HTML and CSS UI components, templates, and code snippets, including typography, forms, buttons, navigation and other interface elements, as well as optional functionality provided by JavaScript extensions. Foundation is maintained by ZURB and is an open source project.  
ef.js ef.js is an elegant HTML template engine & basic framework.  
Vue.js Vue.js is an open-source JavaScript framework for building user interfaces and single-page applications.  
UIKit UIkit is a lightweight and modular front-end framework for developing fast and powerful web interfaces.  
TYPO3 CMS TYPO3 is a free and open-source web content management system written in PHP. It is released under the GNU General Public License. It can run on several web servers, such as Apache or IIS, on top of many operating systems, among them Linux, Microsoft Windows, FreeBSD, macOS and OS/2.  
RequireJS RequireJS is a JavaScript library and file loader which manages the dependencies between JavaScript files and in modular programming. It also helps to improve the speed and quality of the code.  
React React is a JavaScript library for building user interfaces. It is maintained by Facebook and a community of individual developers and companies. React can be used as a base in the development of single-page or mobile applications.  
MooTools MooTools is a lightweight, object-oriented JavaScript framework. It is released under the free, open-source MIT License.  
Laravel Laravel is a free, open-source PHP web framework, created by Taylor Otwell and intended for the development of web applications following the model-view-controller architectural pattern and based on Symfony.  
GraphQL GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015.  
Google Web Toolkit Google Web Toolkit, or GWT Web Toolkit, is an open-source set of tools that allows web developers to create and maintain complex JavaScript front-end applications in Java. Other than a few native libraries, everything is Java source that can be built on any supported platform with the included GWT Ant build files.  
Express.js Express.js, or simply Express, is a web application framework for Node.js, released as free and open-source software under the MIT License. It is designed for building web applications and APIs. It has been called the de facto standard server framework for Node.js.  
CodeIgniter CodeIgniter is an open-source software rapid development web framework, for use in building dynamic web sites with PHP.  
Backbone.js Backbone.js is a JavaScript library with a RESTful JSON interface and is based on the Model-view-presenter application design paradigm. Backbone is known for being lightweight, as its only hard dependency is on one JavaScript library, Underscore.js, plus jQuery for use of the full library.  
AngularJS AngularJS is a JavaScript-based open-source front-end web application framework mainly maintained by Google and by a community of individuals and corporations to address many of the challenges encountered in developing single-page applications.  
JavaScript JavaScript, often abbreviated as JS, is a high-level, interpreted programming language that conforms to the ECMAScript specification. It is a language which is also characterized as dynamic, weakly typed, prototype-based and multi-paradigm.  
Nginx Nginx is a web server which can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache.  
Jetty Jetty is a Java HTTP (Web) server and Java Servlet container Java Servlets/JSP
Joomla Joomla is a free and open-source content management system (CMS) for publishing web content. PHP
JavaServer Faces (JSF) JavaServer Faces (JSF) is a Java specification for building component-based user interfaces for web applications. Java Servlets/JSP
Ruby Ruby is a dynamic, reflective, object-oriented, general-purpose programming language.  
MongoDB MongoDB is a free and open-source cross-platform document-oriented database program.  
Django Django is a free and open-source web framework, written in Python, which follows the model-view-template (MVT) architectural pattern.  
Node.js Node.js is an open-source, cross-platform JavaScript runtime environment for developing a diverse variety of tools and applications.  
Citrix Citrix Systems, Inc. is an American multinational software company that provides server, application and desktop virtualization, networking, software as a service (SaaS), and cloud computing technologies.  
JBoss The JBoss Enterprise Application Platform (or JBoss EAP) is a subscription-based/open-source Java EE-based application server runtime platform used for building, deploying, and hosting highly-transactional Java applications and services. Java Servlets/JSP
Elasticsearch Elasticsearch is a search engine based on Lucene.  
Apache Struts Apache Struts is an open-source web application framework for developing Java EE web applications. Java Servlets/JSP
XML Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.  
PostgreSQL PostgreSQL, often simply Postgres, is an object-relational database (ORDBMS) - i.e. a RDBMS, with additional (optional use) “object” features - with an emphasis on extensibility and standards-compliance.  
IBM DB2 IBM DB2 contains database server products developed by IBM.  
Sybase/ASE SAP ASE (Adaptive Server Enterprise), originally known as Sybase SQL Server, and also commonly known as Sybase DB or ASE, is a relational model database server product for businesses developed by Sybase Corporation which became part of SAP AG.  
CGI Common Gateway Interface (CGI) offers a standard protocol for web servers to interface with executable programs running on a server that generate web pages dynamically.  
Proxy Servers A proxy server is a server (a computer system or an application) that acts as an intermediary for requests from clients seeking resources from other servers.  
SSI (Server Side Includes) Server Side Includes (SSI) is a simple interpreted server-side scripting language used almost exclusively for the Web.  
Cisco Cisco Systems, Inc. is an American multinational corporation technology company headquartered in San Jose, California, that designs, manufactures and sells networking equipment worldwide.  
Novell Novell Directory Services (NDS) is a popular software product for managing access to computer resources and keeping track of the users of a network, such as a company’s intranet, from a single point of administration.  
Macromedia JRun JRun is a J2EE application server, originally developed in 1997 as a Java Servlet engine by Live Software and subsequently purchased by Allaire, who brought out the first J2EE compliant version.  
BEA Systems WebLogic Server Oracle WebLogic Server is a Java EE application server currently developed by Oracle Corporation. Java Servlets/JSP
Lotus Domino IBM Notes and IBM Domino are the client and server, respectively, of a collaborative client-server software platform sold by IBM.  
MySQL MySQL is an open-source relational database management system (RDBMS).  
Oracle Oracle Database (commonly referred to as Oracle RDBMS or simply as Oracle) is an object-relational database management system produced and marketed by Oracle Corporation.  
Microsoft SQL Server Microsoft SQL Server is a relational database management system developed by Microsoft.  
PHP PHP is a server-side scripting language designed primarily for web development but is also used as a general-purpose programming language.  
Outlook Web Access Outlook on the web (previously called Exchange Web Connect, Outlook Web Access, and Outlook Web App in Office 365 and Exchange Server 2013) is a personal information manager web app from Microsoft. ASP.NET, IIS, Microsoft Windows
Apache/NCSA HTTP Server The Apache HTTP Server, colloquially called Apache, is the world’s most used web server software.  
Apache Tomcat Apache Tomcat, often referred to as Tomcat, is an open-source Java Servlet Container developed by the Apache Software Foundation (ASF). Java Servlets/JSP
WordPress WordPress is a free and open-source content management system (CMS) based on PHP and MySQL. XML, PHP
Macromedia ColdFusion Adobe ColdFusion is a commercial rapid web application development platform created by JJ Allaire in 1995.  
Unix/Linux Unix is a family of multitasking, multiuser computer operating systems that derive from the original AT&T Unix, developed in the 1970s at the Bell Labs research center by Ken Thompson, Dennis Ritchie, and others.  
Microsoft Windows Microsoft Windows (or simply Windows) is a metafamily of graphical operating systems developed, marketed, and sold by Microsoft.  
ASP.NET ASP.NET is an open-source server-side web application framework designed for web development to produce dynamic web pages. IIS, Microsoft Windows
Front Page Server Extensions (FPSE) FrontPage Server Extensions are a software technology that allows Microsoft FrontPage clients to communicate with web servers, and provide additional functionality intended for websites.  
IIS Internet Information Services (IIS, formerly Internet Information Server) is an extensible web server created by Microsoft for use with Windows NT family. Microsoft Windows
WebDAV Web Distributed Authoring and Versioning (WebDAV) is an extension of the Hypertext Transfer Protocol (HTTP) that allows clients to perform remote Web content authoring operations.  
ASP Active Server Pages (ASP), later known as Classic ASP or ASP Classic, is Microsoft’s first server-side script engine for dynamically generated web pages. IIS, Microsoft Windows
Java Servlets/JSP A Java servlet is a Java program that extends the capabilities of a server.  
jQuery jQuery is a cross-platform JavaScript library designed to simplify the client-side scripting of HTML.  

Data Guard

Data Guard is a security feature that can be used to prevent the leakage of sensitive information from an application. This could be credit card numbers or Social Security numbers (CCN, SSN, etc.). Once this feature is enabled, sensitive data is either blocked or masked, depending on the configuration.

In this example, we enable the data guard violation in blocking mode. In the detailed configuration, we enable enforcement of data guard and specify which items are being protected against information leakage. Note that if blocking is enabled, data masking will have no effect in this case.

{
    "policy": {
        "name": "dataguard_blocking",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_DATA_GUARD",
                    "alarm": true,
                    "block": true
                }
            ]
        },
        "data-guard": {
            "enabled": true,
            "maskData": true,
            "creditCardNumbers": true,
            "usSocialSecurityNumbers": true,
            "enforcementMode": "ignore-urls-in-list",
            "enforcementUrls": []            
        }
    }
}

Masking

Masking is used when we do not want to block the page entirely, but want to mask all sensitive data in the response.

In this example, we enable data guard in alarm mode. In the detailed configuration, we enable enforcement of data guard and specify which items are being protected against information leakage.

{
    "policy": {
        "name": "nginx_default_policy",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_DATA_GUARD",
                    "alarm": true,
                    "block": false
                }
            ]
        },
        "data-guard": {
            "enabled": true,
            "maskData": true,
            "creditCardNumbers": true,
            "usSocialSecurityNumbers": true,
            "enforcementMode": "ignore-urls-in-list",
            "enforcementUrls": []
        }
    }
}

File Types

A user can enable/disable specific file types in the policy.

In this example, we enable the file type violation in blocking mode. In the detailed configuration, we allow the * wildcard entity which would allow all file types by default. In the last section, we explicitly disable the bat file type. This is an example of allowing all, but specifically blocking (blacklisting) certain items. You may add as many file types as you wish, each declared in its own curly brackets, along with the "allowed": false directive.

{
    "policy": {
        "name": "policy1",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_FILETYPE",
                    "alarm": true,
                    "block": true
                }
            ]
        },
        "filetypes": [
            {
                "name": "*",
                "type": "wildcard",
                "allowed": true,
                "checkPostDataLength": false,
                "postDataLength": 4096,
                "checkRequestLength": false,
                "requestLength": 8192,
                "checkUrlLength": true,
                "urlLength": 2048,
                "checkQueryStringLength": true,
                "queryStringLength": 2048,
                "responseCheck": false
            },
            {
                "name": "bat",
                "allowed": false
            }
        ]
    }
}    

Allowed Methods

In the policy, you can specify what methods to allow or disallow.

In this example, we enable the illegal method violation in blocking mode. In the methods configuration, we define which of the methods are allowed, and how they will be treated in terms of flow. Note that the “act as” does not imply enforcement on the method as the “act as”.

{
    "policy": {
        "name": "blocking_policy",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_METHOD",
                    "alarm": true,
                    "block": true
                }
            ]
        },
        "methods": [
            {
                "name": "GET"
            },
            {
                "name": "POST"
            },
            {
                "name": "HEAD"
            },
            {
                "name": "PUT"
            },
            {
                "name": "PATCH"
            },
            {
                "name": "DELETE"
            },
            {
                "name": "OPTIONS"
            }
        ]
    }
}

Response Codes

Response codes are a general setting that defines which response codes are acceptable, while all others will be blocked.

In this example, we enable the response status codes violation in blocking mode. In the general configuration, we define which of the response codes are allowed. This would mean that all others will be considered as illegal response codes and will be blocked. In this configuration, you specify a list of comma-separated response codes that are allowed.

{
    "policy": {
        "name": "allowed_response",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_HTTP_RESPONSE_STATUS",
                    "alarm": true,
                    "block": true
                }
            ]
        },
        "general": {
            "allowedResponseCodes": [
                400,
                401,
                403,
                404,
                502,
                499
            ]
        }
    }
}

Parameters

When configuring handling of parameters, it is a bit different from other configurations we have dealt with earlier, where we enable a violation and configure its details. With parameters, there are a number of independent violations that need to be enabled on their own, as well as a parameter section to define further customization. The full list of parameter violations can be extracted from the above violation list.

{
    "policy": {
        "name": "parameters_blocking",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_PARAMETER_MULTIPART_NULL_VALUE",
                    "alarm": true,
                    "block": true
                },
                {
                    "name": "VIOL_PARAMETER_NAME_METACHAR",
                    "alarm": true,
                    "block": true
                },
                {
                    "name": "VIOL_PARAMETER_VALUE_METACHAR",
                    "alarm": true,
                    "block": true
                }
            ]
        },
        "parameters": [
            {
                "checkMetachars": true,
                "parameterLocation": "any",
                "valueType": "auto-detect",
                "metacharsOnParameterValueCheck": true,
                "name": "*",
                "type": "wildcard",                
            }
        ]
    }
}

In this example we configure allowed meta-characters in parameter name and value.

{
    "policy": {
        "name": "parameters_allowed_metachars",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_PARAMETER_MULTIPART_NULL_VALUE",
                    "alarm": true,
                    "block": true
                },
                {
                    "name": "VIOL_PARAMETER_NAME_METACHAR",
                    "alarm": true,
                    "block": true
                },
                {
                    "name": "VIOL_PARAMETER_VALUE_METACHAR",
                    "alarm": true,
                    "block": true
                }
            ]
        },
        "parameters": [
            {
                "checkMetachars": true,
                "sensitiveParameter": false,
                "parameterLocation": "any",
                "valueType": "auto-detect",
                "nameMetacharOverrides": [
                    {
                        "isAllowed": true,
                        "metachar": "0x3c"
                    },
                    {
                        "isAllowed": true,
                        "metachar": "0x3e"
                    }
                ],
                "metacharsOnParameterValueCheck": true,
                "allowEmptyValue": true,
                "checkMaxValueLength": false,
                "valueMetacharOverrides": [
                    {
                        "isAllowed": true,
                        "metachar": "0x3c"
                    },
                    {
                        "isAllowed": true,
                        "metachar": "0x3e"
                    }
                ],
                "name": "*",
                "level": "global",
                "allowRepeatedParameterName": true,
                "attackSignaturesCheck": true,
                "signatureOverrides": [],
                "type": "wildcard",                
            }
        ]
    }
}

In this example, we define a sensitive parameter “mypass” configuration.

{
    "policy": {
        "name": "parameters_sensitive",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [
                {
                    "name": "VIOL_PARAMETER_MULTIPART_NULL_VALUE",
                    "alarm": true,
                    "block": false
                },
                {
                    "name": "VIOL_PARAMETER_NAME_METACHAR",
                    "alarm": true,
                    "block": false
                },
                {
                    "name": "VIOL_PARAMETER_VALUE_METACHAR",
                    "alarm": true,
                    "block": false
                }
            ]        
        },
        "sensitive-parameters": [
            {
                "name": "mypass"
            }
        ]
    }
}

Blacklisting and Whitelisting

It is possible to define IP addresses or ranges that will be blacklisted or whitelisted despite the rest of the configuration settings in the policy.

In this example, we use the default configuration while enabling the blacklisting violation. In the configuration section, we define:

- A whitelisted IP 1.1.1.1
- A blacklisted IP 2.2.2.2
- A whitelisted range of IPs 3.3.3.0/24
{
    "policy": {
        "name": "blacklist_whitelist",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "blocking-settings": {
            "violations": [                
                {
                    "name": "VIOL_BLACKLISTED_IP",
                    "alarm": true,
                    "block": true
                }
            ]
        },
        "whitelist-ips": [
            {
                "blockRequests": "never",
                "neverLogRequests": false,
                "ipAddress": "1.1.1.1",
                "ipMask": "255.255.255.255"
            },
            {
                "blockRequests": "always",
                "ipAddress": "2.2.2.2",
                "ipMask": "255.255.255.255"
            },
            {
                "blockRequests": "never",
                "neverLogRequests": false,
                "ipAddress": "3.3.3.0",
                "ipMask": "255.255.255.0"
            }
        ]
    }
}

Additional Configuration Options

XFF Headers and Trust

XFF trust is disabled by default but can be enabled.

In this example, we use the default configuration but enable the trust of XFF header.

{
    "policy": {
        "name": "xff_enabled",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "general": {
            "customXffHeaders": [],
            "trustXff": true
        }
    }
}

In this example, we configure a policy with a custom-defined XFF header.

{
    "policy": {
        "name": "xff_custom_headers",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",
        "general": {
            "customXffHeaders": [
                "xff"
            ],
            "trustXff": true
        }
    }
}

Blocking Page Customization

You can customize the blocking page text and formatting to suit your particular design requirements.

In this example, we use the default configuration but modify the response page that is displayed to the customer.

 {
    "policy": {
        "name": "blocking_page",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking",    
        "response-pages": [
            {
                "responseContent": "<html><head><title>Custom Reject Page</title></head><body>This is a custom response page, it is supposed to overwrite the default page with custom text.<br><br>Your support ID is: <%TS.request.ID()%><br><br><a href='javascript:history.back();'>[Go Back]</a></body></html>",
                "responseHeader": "HTTP/1.1 302 OK\\r\\nCache-Control: no-cache\\r\\nPragma: no-cache\\r\\nConnection: close",
                "responseActionType": "custom",
                "responsePageType": "default"
            }
        ]
    }
}

AJAX Response Page for Single Page Applications (SPAs)

There is a special scenario where default or regular custom response pages cannot be used. SPAs (Single Page Applications) are applications that provide application functionality within the boundaries of a single HTML page. Once a SPA application has been loaded in the browser, it typically makes REST API calls to remote resources expecting JSON response bodies rather than HTML markup. If this SPA application were to receive a default HTML-formatted block page, it would not be able to interpret this, likely causing an application error.

A way to handle such a situation is via configuring an AJAX response page. The AJAX response page will cause a pop-up to appear on the client browser, informing them that the request has been blocked.

In this example, we set up an AJAX response page.

{
  "policy" : {
    "name": "NGINX-SPA",
    "description": "Policy with AJAX response page enabled for blocking AJAX requests",
    "template": {
      "name": "POLICY_TEMPLATE_NGINX_BASE"
    },
    "enforcementMode": "blocking",
    "response-pages": [
      {
        "responsePageType": "ajax",
        "ajaxEnabled": true,
        "ajaxPopupMessage": "My customized popup message! Your support ID is: <%TS.request.ID()%>"
      }
    ]
  }
}

Response Page for gRPC Applications

Another scenario where default or regular custom response pages cannot be used is in the context of a gRPC application. If a gRPC client were to receive a block page, it would not be able to interpret this, likely causing an application error.

A way to handle such a situation is via configuring a custom response in a format that a gRPC client can interpret in its error handling code. This is an example configuration for this scenario.

{
  "policy" : {
    "name": "NGINX-GRPC",
    "description": "Policy with gRPC response page enabled for blocking gRPC requests",
    "template": {
      "name": "POLICY_TEMPLATE_NGINX_BASE"
    },
    "enforcementMode": "blocking",
    "response-pages": [
      {
        "responseContent": "",
        "responseHeader": "HTTP/1.1 403 FORBIDDEN\r\nContent-Type: application/grpc+proto\r\nGrpc-status: 7\r\nGrpc-message: Blocked by NGINX App Protect, Your support ID is <%TS.request.ID()%>\r\nSupport-ID: <%TS.request.ID()%>\r\nCache-Control: no-cache\r\nPragma: no-cache\r\nConnection: close",
        "responseActionType": "custom",
        "responsePageType": "default"
      }
    ]
  }
}

Modifying Configurations

What we have been seeing so far has been related to making changes by actually overriding specific configuration values. What would happen in the case we wanted to remove a specific configuration entity from the policy. For example, let’s say we have added file types “aaa”, “bbb”, and “ccc”, and now we wish to remove “bbb” from the list of disallowed file types. Deleting this entity from the declarative configuration file will simply mean that this entity will be left intact when the policy is rebuilt, meaning that the entity is still in the disallowed file types list. To resolve such situations, we have a modifications section where we can force modification where otherwise it is not possible using direct declarative configuration.

There is a specific section named modifications where we can configure items to be removed/deleted or forcefully modified in the policy.

In this example, we specify that we wish to remove the file type log from the disallowed file types list.

{
    "policy": {
        "name": "modifying_disallowed_file_types",
        "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
        "applicationLanguage": "utf-8",
        "enforcementMode": "blocking"
    },
    "modifications": [
            {
            "entityChanges": {
                "type": "explicit"
            },
            "entity": {
                "name": "log"
            },
            "action": "delete",
            "entityType": "filetype"
        }
    ]
}

Directives

Global Directives

Global configuration consists of a series of nginx.conf directives at the http context controlling aspects that are not specific to a specific application.

When applied to a cluster, all cluster members will get the same globals as expected.

Note: Whether an incoming request is inspected by NGINX App Protect may be determined by the URL in the request. This happens if you configure app_protect_enable and app_protect_policy_file directives in the location scope. In the case where the URL itself has violations such as bad unescape or illegal metacharacter then the request might be assigned to a location in which NGINX App Protect is disabled or has a relaxed policy that does not detect these violations. Such malicious requests will be allowed without inspection. In order to avoid this, it is recommended to have a basic policy enabled at the http scope or at least at the server scope to process malicious requests in a more complete manner.

Directive Name Syntax Description Default
app_protect_physical_memory_util_thresholds app_protect_physical_memory_util_thresholds high=<number_0-100> low=<number_0-100> Sets the physical memory utilization thresholds for entering (high) and exiting (low) failure mode. When the high threshold is exceeded the system enters failure mode until memory drops below the low threshold. Setting the value of 100 disables this feature. high=low=100 (disabled)
app_protect_cpu_thresholds app_protect_cpu_thresholds high=<number_0-100> low=<number_0-100>
Sets the CPU utilization thresholds for entering and exiting failure mode respectively: when the high threshold is exceeded the system enters failure mode until CPU drops below the low threshold. Setting the value of 100 disables this feature.
Note: The system does not enter failure mode during policy compilation after reload even if the threshold is exceeded.
high=low=100 (disabled)
app_protect_failure_mode_action app_protect_failure_mode_action pass | drop
How to handle requests when the App Protect Enforcer cannot process them, either because it is down, disconnected or because of excessive CPU or memory utilization. There are two values:
  • pass: Pass the request without App Protect Enforcer inspection, a.k.a. “fail-open”.
  • drop: Drop the request by resetting connection. No response page is returned, a.k.a. “fail-close”.
Pass
app_protect_cookie_seed app_protect_cookie_seed <string> A long randomized string that serves to generate the encryption key for the cookies generated by App Protect. The string should contain only alphanumeric characters and be no longer than 1000 characters. Auto-generated random string

App Protect Specific Directives

This table summarizes the nginx.conf directives for NGINX App Protect functionality.

Directive Name Syntax Functionality nginx.conf Contexts Example
load_module load_module <library_file_path> NGNIX directive to load the App Protect module. It must be invoked with the App Protect library path Global load_module /lib/app_protect.so
app_protect_enable app_protect_enable on | off Whether to enable App Protect at the respective context. If not present, inherits from the parent context HTTP, Server, Location app_protect_enable on
app_protect_policy_file app_protect_policy_file <file_path> Set a App Protect policy configuring behavior for the respective context. HTTP, Server, Location app_protect_policy /config/waf/strict_policy.json
app_protect_security_log_enable app_protect_security_log_enable on | off Whether to enable the App Protect per-request log at the respective context. HTTP, Server, Location app_protect_security_log_enable on
app_protect_security_log_settings app_protect_security_log_settings <file_path> <destination> Specifies the per-request logging: what to log and where HTTP, Server, Location app_protect_security_log_settings /config/waf/log_illegal.json syslog:localhost:522

Horizontal Scaling

NGINX App Protect can be deployed in multiple instances that share the traffic to the same applications. In that case all the instances must share the same configuration files. It is your responsibility to synchronize the files on all instances. You also have to provide a load balancing solution in front of those instances such as another NGINX instance.

When deploying multiple scalability instances you have to add the app_protect_cookie_seed directive to nginx.conf in the http block:

...
http {
    ...
    app_protect_cookie_seed jkldsf90upiokasdj120;
    ...
    server {
        listen       80;
...
}
...

As the argument of this directive, put a random alphanumeric string of at least 20 characters length (but not more than 1000 characters). That seed is used by NGINX App Protect to generate the encryption key for the cookies it creates. These cookies are used for various purposes such as validating the integrity of the cookies generated by the application.

In the absence of this directive, App Protect generates a random string by itself. In that case, each instance will have a different seed. A cookie created and encrypted on one instance of App Protect will fail to be decrypted when sent by the same client to another App Protect instance having a different encryption key.

Failure Mode

If the App Protect daemons are down or disconnected from the NGINX workers, there are two modes of operation until they are up and connected again:

  • Pass the traffic without inspection. Use this when preferring availability over security. This mode is also known as “fail open”.
  • Drop the traffic. Use this when preferring security over availability. This mode is also known as “fail closed”.

The default is to pass, fail open, but you can control this using the app_protect_failure_mode_action directive with one argument with two possible values: “pass” or “fail” for the two above options.

This directive is also placed in the http block of the nginx.conf file.

...
http {
    ...
    app_protect_failure_mode_action drop;
    ...
    server {
        listen       80;
...
}
...

Violations

App Protect violations are rated by the App Protect algorithms to help distinguish between attacks and potential false positive alerts. A violation rating is a numerical rating that our algorithms give to requests based on the presence of violation(s). Each violation type and severity contributes to the calculation of the final rating. The final rating then defines the action taken for the specific request. As per the default policy, any violation rating of 1, 2 and 3 will not cause the request to be blocked and only a log will be generated with alerted status. If the violation rating is 4 or 5, the request is blocked: a blocking page is displayed and a log generated for the transaction with blocked status. Violation ratings are displayed in the logs by default.

Supported Violations

The following violations are supported and can be enabled by turning on the alarm and/or block flags.

Violation Name Title Enabled Flags in Default Template Description Comment
VIOL_ASM_COOKIE_MODIFIED Modified ASM cookie Alarm The system checks that the request contains an ASM cookie that has not been modified or tampered with. Blocks modified requests.  
VIOL_ATTACK_SIGNATURE Attack signature detected N/A The system examines the HTTP message for known attacks by matching it against known attack patterns. Determined per signature set.
VIOL_BLACKLISTED_IP IP is blacklisted Alarm The violation is issued when a request comes from an IP address that falls in the range of an IP address exception marked for “always blocking”, that is, the black list of IPs. Would trigger Violation Rating of 5.
VIOL_COOKIE_EXPIRED Expired timestamp Alarm The system checks that the timestamp in the HTTP cookie is not old. An old timestamp indicates that a client session has expired. Blocks expired requests. The timestamp is extracted and validated against the current time. If the timestamp is expired and it is not an entry point, the system issues the Expired Timestamp violation.  
VIOL_COOKIE_LENGTH Illegal cookie length Alarm The system checks that the request does not include a cookie header that exceeds the acceptable length specified in the security policy. Determined by policy setting which is disabled in default template.
VIOL_COOKIE_MALFORMED Cookie not RFC-compliant Alarm

This violation occurs when HTTP cookies contain at least one of the following components:

  • Quotation marks in the cookie name.
  • A space in the cookie name.
  • An equal sign (=) in the cookie name. Note: A space between the cookie name and the equal sign (=), and between the equal sign (=) and cookie value is allowed.
  • An equal sign (=) before the cookie name.
  • A carriage return (hexadecimal value of 0xd) in the cookie name.
 
VIOL_COOKIE_MODIFIED Modified domain cookie(s) Alarm The system checks that the web application cookies within the request have not been tampered, and the system checks that the request includes a web application cookie defined in the security policy. Determined by cookie type: applied to “enforced” cookies.
VIOL_DATA_GUARD Data Guard: Information leakage detected Alarm The system examines responses and searches for sensitive information. Controlled by the DG enable flag which is disabled in default template.
VIOL_ENCODING Failed to convert character Alarm The system detects that one of the characters does not comply with the configured language encoding of the web application’s security policy. Enforced by NGINX core, reported by App Protect.
VIOL_EVASION Evasion technique detected Alarm This category contains a list of evasion techniques that attackers use to bypass detection.  
VIOL_FILETYPE Illegal file type Alarm The system checks that the requested file type is configured as a valid file type, or not configured as an invalid file type, within the security policy. Only for disallowed file types.
VIOL_HEADER_LENGTH Illegal header length Alarm The system checks that the request includes a total HTTP header length that does not exceed the length specified in the security policy. The actual size in default policy is 4 KB
VIOL_HEADER_METACHAR Illegal meta character in header Alarm The system checks that the values of all headers within the request only contain meta characters defined as allowed in the security policy.  
VIOL_HTTP_PROTOCOL HTTP protocol compliance failed Alarm This category contains a list of validation checks that the system performs on HTTP requests to ensure that the requests are formatted properly.  
VIOL_HTTP_RESPONSE_STATUS Illegal HTTP response status Alarm The server response contains an HTTP status code that is not defined as valid in the security policy.  
VIOL_JSON_FORMAT JSON data does not comply with format settings Alarm The system checks that the request contains JSON content and complies with the various request limits within the defense configuration in the security policy’s JSON profile. Enforces valid JSON requests and protects the server from JSON parser attacks. This violation is generated when a problem is detected in a JSON request, generally checking the message according to boundaries such as the message’s size and meta characters in parameter value. Controlled from the default JSON profile.
VIOL_JSON_MALFORMED Malformed JSON data Alarm The system checks that the request contains JSON content that is well-formed. Enforces parsable JSON requests.  
VIOL_METHOD Illegal method Alarm The system checks that the request references an HTTP request method that is found in the security policy. Enforces desired HTTP methods; GET and POST are always allowed.

These HTTP methods are supported:

  • GET
  • HEAD
  • POST
  • PUT
  • PATCH
  • DELETE
  • OPTIONS
VIOL_POST_DATA_LENGTH Illegal POST data length Alarm The system checks that the request contains POST data whose length does not exceed the acceptable length specified in the security policy. In * file type entity. This check is disabled by default.
VIOL_QUERY_STRING_LENGTH Illegal query string length Alarm The system checks that the request contains a query string whose length does not exceed the acceptable length specified in the security policy. In * file type entity. Actual size is 2 KB.
VIOL_REQUEST_LENGTH Illegal request length Alarm The system checks that the request length does not exceed the acceptable length specified in the security policy per the requested file type. In * file type entity. This check is disabled by default.
VIOL_REQUEST_MAX_LENGTH Request length exceeds defined buffer size Alarm The system checks that the request length is not larger than the maximum memory buffer size of the ASM. Note that this is a BIG-IP unit parameter that protects the ASM from consuming too much memory across all security policies which are active on the device. Default is 10MB
VIOL_URL_LENGTH Illegal URL length Alarm The system checks that the request is for a URL whose length does not exceed the acceptable length specified in the security policy. In * file type entity. Actual size is 2 KB.
VIOL_URL_METACHAR Illegal meta character in URL Alarm The system checks that the incoming request includes a URL that contains only meta characters defined as allowed in the security policy. Enforces a desired set of acceptable characters.  
VIOL_XML_FORMAT XML data does not comply with format settings Alarm The system checks that the request contains XML data that complies with the various document limits within the defense configuration in the security policy’s XML profile. Enforces proper XML requests and the data failed format/defense settings such as the maximum document length. This violation is generated when a problem in an XML document is detected (for example, an XML bomb), generally checking the message according to boundaries such as the message’s size, maximum depth, and maximum number of children. Controlled by the default XML profile
VIOL_XML_MALFORMED Malformed XML data Alarm The system checks that the request contains XML data that is well-formed, according to W3C standards. Enforces proper XML requests.  
VIOL_RATING_THREAT Request is likely a threat Alarm and Block The combination of violations in this request determined that the request is likely to be a threat. For VR = 4 or 5
VIOL_RATING_NEED_EXAMINATION Request needs further examination Disabled The combination of violations could not determine whether the request is a threat or violations are false positives thus requiring more examination. For VR = 3
VIOL_PARAMETER_MULTIPART_NULL_VALUE Null in multi-part parameter value Disabled

The system checks that the multi-part request has a parameter value that does not contain the NULL character (0x00). If a multipart parameter with binary content type contains NULL in its value, the enforcer issues this violation. The exceptions to this are:

  • If that parameter is configured in the policy as “Ignore value”.
  • If that parameter is configured in the security policy as “user-input file upload”.
  • If the parameter has a content-type that contains the string ‘XML’ and the parameter value contains a valid UTF16 encoded XML document (the encoding is valid). In this case NULL is allowed as it is part of the UTF16 encoding.
 
VIOL_PARAMETER_NAME_METACHAR Illegal meta character in parameter name Alarm The system checks that all parameter names within the incoming request only contain meta characters defined as allowed in the security policy.  
VIOL_PARAMETER_VALUE_METACHAR Illegal meta character in value Alarm The system checks that all parameter values, XML element/attribute values, or JSON values within the request only contain meta characters defined as allowed in the security policy. Enforces proper input values.  

HTTP Compliance Sub-Violations

The following table specifies the HTTP Compliance sub-violation settings. All are supported in NGINX, but not all are enabled in the default App Protect security template. The table specifies which. Some of the checks are enforced by NGINX Plus and App Protect only gets a notification. Note: In this case, the request is always blocked regardless of the App Protect policy.

Sub-Violation Default Template Enforced by Description Comment
Unparsable request content Enabled NGINX This violation is triggered when the system’s parser cannot parse the message.  
Several Content-Length headers Enabled NGINX More than one content-length header is a non RFC violation. Indicates an HTTP response splitting attack.  
POST request with Content-Length: 0 Disabled App Protect    
Null in request Enabled Null in header - NGINX The system issues a violation for requests with a NULL character anywhere in the request (except for a NULL in the binary part of a multipart request).  
Null in body Enabled App Protect    
No Host header in HTTP/1.1 request Enabled NGINX Examines requests using HTTP/1.1 to see whether they contain a “Host” header.  
Multiple host headers Enabled App Protect Examines requests to ensure that they contain only a single “Host” header.  
Host header contains IP address Enabled App Protect The system verifies that the request’s host header value is not an IP address to prevent non-standard requests.  
High ASCII characters in headers Enabled NGINX Checks for high ASCII characters in headers (greater than 127).  
Header name with no header value Disabled App Protect The system checks for a header name without a header value.  
CRLF characters before request start Enabled App Protect Examines whether there is a CRLF character before the request method. If there is, the system issues a violation.  
Content length should be a positive number Enabled NGINX The Content-Length header value should be greater than zero; only a numeric positive number value is accepted.  
Chunked request with Content-Length header Enabled App Protect The system checks for a Content-Length header within chunked requests.  
Check maximum number of parameters Enabled: 500 App Protect The system compares the number of parameters in the request to the maximum configured number of parameters.  
Check maximum number of headers Enabled : 50 App Protect The system compares the request headers to the maximal configured number of headers.  
Body in GET or HEAD requests Disabled App Protect Examines GET and HEAD requests which have a body.  
Bad multipart/form-data request parsing Enabled App Protect When the content type of a request header contains the substring “Multipart/form-data”, the system checks whether each multipart request chunk contains the strings “Content-Disposition” and “Name”. If they do not, the system issues a violation.  
Bad multipart parameters parsing Enabled App Protect
The system checks the following:
  1. A boundary follows immediately after request headers.
  2. The parameter value matches the format: ‘name=”param_key”;rn.
  3. A chunked body contains at least one CRLF.
  4. A chunked body ends with CRLF.
  5. Final boundary was found on multipart request.
  6. There is no payload after final boundary.

If one of these is false, the system issues a violation.

 
Bad HTTP version Enabled NGINX Enforces legal HTTP version number (only 0.9 or higher allowed).  
Bad host header value Learn Detected non RFC compliant header value. NGINX  

Evasion Techniques Sub-Violations

The following table specifies the Evasion Techniques sub-violation settings. All are supported in NGINX Plus.

Sub-Violation Default Template Description Comment
%u decoding Enabled Performs Microsoft %u unicode decoding (%UXXXX where X is a hexadecimal digit). For example, the system turns a%u002fb to a/b. The system performs this action on URI and parameter input to evaluate if the request contains an attack.  
Apache whitespace Enabled The system detects the following characters in the URI: 9 (0x09), 11 (0x0B), 12 (0x0C), and 13 (0x0D).  
Bad unescape Enabled The system detects illegal HEX encoding. Reports unescaping errors (such as %RR).  
Bare byte decoding Enabled The system detects higher ASCII bytes (greater than 127).  
Directory traversals Enabled Ensures that directory traversal commands like ../ are not part of the URL. While requests generated by a browser should not contain directory traversal instructions, sometimes requests generated by JavaScript have them.  
IIS backslashes Enabled Normalizes backslashes () to slashes (/) for further processing.  
IIS Unicode codepoints Enabled Handles the mapping of IIS specific non-ASCII codepoints. Indicates that, when a character is greater than ‘0x00FF’, the system decodes %u according to an ANSI Latin 1 (Windows 1252) code page mapping. For example, the system turns a%u2044b to a/b. The system performs this action on URI and parameter input.  
Multiple decoding Enabled: 3 The system decodes URI and parameter values multiple times according to the number specified before the request is considered an evasion.