Add security protection

CADS edition, provides an intent-based security protection for your web applications and APIs from OWASP Top-10 attacks and exploits. With CADS security protection, you can define your desired business intent without having to understand the complexities of OWASP Top-10, network, policies, and other application security configuration that the traffic passes through. In addition to the web application firewall and bot management, the service also provides visibility into security insights that provide real-time monitoring of traffic violations and vulnerabilities.

Benefits

  1. Automatically assigns the business intent to security policies.
  2. Translates high-level security requests into relevant configuration changes.
  3. Simplify deployment and management of security for applications.
  4. Get valuable insights and visibility into security events and automate remediation actions.
  5. Get continuous protection with auto-update of WAF or bot signature and IP reputation feed.

Prerequisites

Complete the following prerequisites before you add security protection to your application. By default, security protection is disabled.

  1. Sign up for Citrix Cloud.
  2. Request for Citrix App Delivery and Security Service – Citrix Managed entitlement.
  3. Set up application environment.

For more information, see Get started with Citrix App Delivery and Security service topic.

How Citrix App Delivery and Security Service – Citrix Managed security protection works

The Citrix App Delivery and Security Service – Citrix Managed security protection has a collection of security checks that protect your application from malicious attacks, software vulnerabilities, SQL database vulnerabilities, errors in the code design, and failures to secure websites that host or can access sensitive information. You can enable and configure security checks to protect your application from various security attacks.

Security check

A security check is a check that inspects malicious or unknown attacks on your web applications. The security check use heuristics, positive security, and other detection techniques to identify attacks. You can configure a security check by first enabling it and then configuring it to block requests, log request details, add exceptions, or define rules to examine traffic.

The CADS security checks are classified into the following categories:

  • Basic security check. Web security protection applicable to any content type.
  • HTML security check. Web security protection applicable only to HTML-based websites and to HTML portions of Web 2.0 sites that contain both HTML and XML content.
  • JSON security check. Web security protection applicable only to JSON-based websites and to JSON content type in Web 2.0 sites.

Signatures

Signatures are configurable rules to simplify the task of protecting your websites from attacks. A signature represents a pattern of a component attack on an operating system, web server, website, or other resources.

The CADS Security Protection has a built-in default signature object consisting of more than 1,300 signature rules. The CADS Security Protection and Bot signatures can be customized by adding new rules. A signature rule can have multiple patterns and can flag a violation only when all the patterns are matched to avoid false positives.

Actions

All security checks have a set of configurable actions which control how CADS Security Protection can handle a request or response.

Block action

The block action prevents vulnerabilities from attacking your application. By default, security checks have the block action disabled. You must enable if you want to block a request that contains a malicious attack. If block action is not enabled, the CADS service only logs the request data.

Log action

The log action enables you to collect request details that have a malicious attack. The log details can be further investigated for monitoring and analytics purposes. When you enable a security check that the log-only action is auto-enabled for the feature.

Exception (rule)

For security check, an exception is a rule written to allow access to specific data and block the rest. Exceptions are applicable only for a few security checks such as SQL injection, cross-site scripting, Cross-Site Request Forgery (CSRF), Field Consistency, and Cookie Consistency. These rules are written to bypass security validation for false-positive scenarios.

You can configure an exception to bypass security checks for legitimate requests. A security check is performed on the incoming traffic payload and malicious requests, patterns are identified even if they are spread across multiple lines. When examining the traffic, you can apply exceptions to bypass the security check for the following criteria:

  • Incoming traffic with SQL injection attacks that are malicious.
  • Incoming traffic with cross-site scripting attacks that are vulnerable to your web applications.
  • Incoming traffic with cookie consistency attacks to gain access to a legitimate session of the target user.
  • Incoming traffic with field consistency attacks that send unauthorized web from data.
  • Incoming traffic with CSRF attacks induces a user to perform actions that are not intended to perform.

The ADS security protection not only enables you to create an exception but also manages exceptions for the security check through the ADS GUI or API interface.

Example use case 1: Exception for Cross-Site Scripting protection:

Consider a form field dpasswd in the URL, https://adcsvc.example.com/login.php not prone to cross site scripting. The corresponding field can be exempted from the cross site scripting protection. To configure this exception, you can add a rule in which the URL pattern must be defined as https://adcsvc.example.com/login.php(regex), field type must be Form Field, and form field name must be “^dpasswd$(regex)”.

Sample payload URL Field type Form field
https://adcsvc.example.com/login.php?uname=test&dpasswd= foo<script>alert(document.cookie)</script> https://adcsvc\. example\.com/ login\.php Form Field ^dpasswd $

Example use case 2: Exception for cookie consistency validation:

False positives occur when a cookie mismatch is incorrectly flagged as a vulnerability by a scanning tool. To handle such scenarios, you can add an exception for the header cookie that can be exempted from cookie validation. Consider a client sending a login request to the server. On successful login, the server response includes the set-header cookie that contains the JSESSIONID and its value.

Set-Cookie: JSESSIONID=abc123; Path=/; HttpOnly
<!--NeedCopy-->

The client sends the cookie ID in its subsequent request to the server. To handle a false positive or legitimate request, you can add an exception to bypass cookie validation for JSESSIONID for any request coming from the client.

Conditions

Conditions are characteristics that you want to examine in an incoming request. Following are some conditions for which a Citrix App Delivery and Security Service – Citrix Managed evaluates the traffic.

  1. Malicious scripts embedded in a request.
  2. IP addresses or address ranges that requests originate from.
  3. Country or geographical location that requests originate from.
  4. Length of a specified portion of the request, such as the query string.

Get started with CADS service security checks

The CADS service security protection features are classified into three categories, General, WAF, and Bot.

CADS service security protection features

General

  • Allow and block list—Inspects the incoming traffic with rules defined to Allow or Block a client’s access to web application resources, based on parameters such as IP address, subnet, or HTTP request headers.
  • Geo blocking—Restricts unauthorized access based on user’s geographical location.
  • IP reputation—Blocks traffic coming from an IP address with a bad reputation score
  • Rate Limit—Limits the amount of network traffic. For example, if the feature limits the number of incoming requests to 100, then more requests to the web application are blocked. Rate limiting controls traffic flow based on client IP address, client subnet, URL, or URL pattern, and HTTP headers.

WAF

  • SQL injection—Examines HTTP or HTTPS requests and blocks HTML-based, and JSON-based SQL attacks that can affect your web applications.
  • Buffer overflow—Examines if an incoming traffic can cause a buffer overflow on the web server. If the service detects a URL, a cookie, or a header longer than the specified maximum length in a request, it blocks a JSON-based request or HTML based requests to prevent a buffer overflow attack.
  • Cookie Consistency—Examines the cookie sent by the browser and blocks the request if the cookie does not match the cookie in the web application. To resolve a false positive and bypass the security check, you can add an exception.
  • Cross-site scripting—Examines if an attacker inserts malicious code into an incoming request that can have huge implications, such as compromising website security or user authentication. To resolve a false positive and bypass the security check, you can add an exception.
  • Command Injection—Examines if an incoming request has any vulnerable commands. To resolve a false positive and bypass the security check, you can add an exception.
  • CSRF—Inspect HTTP or HTTPS requests and blocks HTML-based, or JSON-based CSRF attacks that can affect your web applications.
  • Field Consistency—Examines web forms returned by users for your application and verifies that web forms were not modified inappropriately by the client. The security check is only for HTML requests that contain a web form, with or without data.
  • WAF Signatures—A list of signature rules is available under different categories to protect your web application against security attacks. The Citrix ADC security protection examines the traffic and blocks the request if it matches a signature pattern. By default, all signatures are enabled.
  • HTTP Security Headers—HTTP response headers can be used to prevent security attacks on the web application by controlling the browser behavior during application access.

Bot

  • Bot Signatures—A list of bot signature rules is available under different categories to protect your web application against security attacks. The Citrix ADC security protection examines the traffic and blocks the request if it matches a signature pattern. By default, all bot signatures are enabled.

Before you enable a security check, you must create a security protection profile or use an existing security profile.

Add a security protection profile

If you already have a security protection profile, you can select and add the profile for your application, otherwise you can create a profile.

Complete the following steps to add a security protection by using the GUI:

  1. Navigate to Applications > Security Protection.
  2. Click Select.

    Add Citrix App Delivery and Security security protection profile

  3. In the Add Security Protection slide, select a security protection profile and click Add.
  4. The profile is added to security protection summary table.
  5. Select and bind the profile to a service.

    Bind Citrix App Delivery and Security security protection to a service

Note:

You can add only one security profile to an application service.

The security protection profile is now added to the application before it is ready to be deployed in the cloud. If you do not see an existing profile in the list, you can create a one.

Create a security protection profile

As a first-time user, you can create a profile for your application. Complete the following steps by using the GUI.

  1. Navigate to Applications > Security Protection.
  2. Click Create.
  3. In the Create Security Protection page, enter a name and configure the following security features:

    1. Allow and Block list
    2. Geo Blocking
    3. IP Reputation
    4. Rate Limit
    5. SQL Injection
    6. Buffer overflow
    7. Cross-site scripting
    8. Cookie Consistency
    9. CSRF
    10. Field consistency
    11. Signatures
    12. HTTP Security Headers
    13. Bot signatures

CADS security protection feature list

  1. Click Create.

    You can view the newly created security protection profile.

    Create a security protection profile

  2. Select and bind the profile to a service.

Note:

You can add only one security profile to an application.

Security protection profile summary list

The profile is added to your application.

Update a security protection profile

If you already have a security protection profile and you prefer to update its details, you can use the edit functionality.

Complete the following steps to update a security protection profile by using the GUI:

  1. Navigate to Applications > Security Protection.
  2. Click Select.
  3. In the Add Security Protection slide, select a security protection profile and click the pencil icon to update.
  4. In the Update Security Protection page, modify details and click Update.
  5. The Add Security Protection page displays the updated profile.
  6. Select the profile and click Add.
  7. The profile is added to security protection summary table.
  8. Select and bind the profile to a service.

    Update a security protection profile

Allow and block list

The Allow and block list functionality enables you to create a security rule to allow or block requests based on user parameters such as IP address, subnet address, or HTTP header.

Allow list. A rule that allows user requests to access internal resources if all conditions configured for the rule match the request.

Block list. A rule that blocks user request to internal resources if all conditions configured for the rule match the request.

Update a security protection profile

Enable allow and block list protection

Before you create a security rule, as a first step, you must enable the security check toggle. If you disable the toggle, the Citrix App Delivery and Security Service – Citrix Managed does not inspect the traffic.

Enable allow and block list protection

Create a rule

As a first-time user, if you do not see a security rule for allow or block list, you can create a one. Complete the following steps to create a rule by using the GUI.

  1. Navigate to Applications > Security Protection.
  2. In the Create New Security Protection > Allow and Block list tab page, enable Allow and Block list protection toggle and click Add Rule.
  3. In the Allow and Block list page, set the following parameters:
    1. Rule name. Name of the rule for an allow list or a block list.
    2. If the following conditions are met. The conditions to define based on user parameters such as IP address, subnet address, or HTTP header. The Citrix App Delivery and Security Service – Citrix Managed security evaluates traffic based on the conditions that you define.
      1. HTTP Request Method. Request method for create, read, update, or delete operations.
        1. Operator. Logical condition to evaluate the HTTP request method.
        2. Value. HTTP request method operation.
      2. HTTP Request Header. Header used in an HTTP request to provide information about the request.
        1. Operator. Logical condition to evaluate the value of specific headers.
        2. Name. Name of the HTTP request header field.
        3. Value. Request header field value.
      3. HTTP Request host name. HTTP host header that has the host name of the client request.
        1. Operator. Logical condition to evaluate the request host name.
        2. Value. Host name value.
      4. HTTP Request URL. HTTP request made by a client to a named host located on the back-end server.
        1. Operator. Logical condition to evaluate the request URL.
        2. Path. Request URL path.
      5. IP Allow and Block list.
        1. Operator. Logical condition to evaluate the IP address of the client request.
        2. Value. IP address or subnet address.
    3. Then do the following Action. Action to apply based on evaluation. Action types are as follows:
      1. Allow. Allow user request to access internal resources.
      2. Drop. Drop user request without sending a response.
      3. Reset. Reset client connection by closing it.
    4. Click Add Rule.

    Create allow or block list rule

You can view the newly created rule on the Create new Security Protection page.

Allow or block list summary view

Click the pencil icon to modify rule details. Otherwise, as a next step you can configure Geo blocking security check.

Update an allow or block rule

Complete the following steps to update a rule by using the GUI:

  1. Navigate to Applications > Security Protection.
  2. Click Add Security Protection.
  3. In the Add Security Protection slide, select a rule and click the pencil icon to edit.
  4. In the Allow and Block list page, edit details and click Update Rule.
  5. You can view the updated rule on the Create new Security Protection page.

Geo blocking

The geo blocking security check enables you to allow or block requests based on a geographical location from where the request originates from. The filter works based on a geo match condition that has a list of countries in an allow list and a block list. If a request matches a geo match condition, then the request is either allowed or blocked based on the location the request originates from.

Enable geo blocking protection

Before you configure geo-blocking, you must enable the security check. When disabled, the Citrix App Delivery and Security Service – Citrix Managed does not allow, or block requests based on the client’s geo location.

Classify geo locations

Complete the following steps to classify geo locations under an allowed or blocked country list:

  1. Navigate to Application > Security Protection > Create New Security Protection > Geo Blocking.
  2. In the Geo Blocking tab section, classify countries under allowed list and blocked list.

    Geo blocking

IP reputation

IP reputation security check blocks unwanted requests coming from an IP address that has a bad reputation score. The security check enables you to classify IP address threat categories as an allowed list and blocked list. If a request matches a condition, the request is either allowed or blocked based on its IP address and its threat category. Some of the key threat categories are spam sources, Windows exploits, botnets, scanners, and so forth.

Enable IP reputation protection

Enable the IP reputation security check to examine traffic for the IP reputation. When disabled, the Citrix App Delivery and Security Service – Citrix Managed does not inspect the traffic for its IP address and threat category.

Classify IP address threat category

Complete the following steps to classify the threat categories as an allowed list or a block list:

  1. Navigate to Application > Security Protection > Create New Security Protection > IP Reputation.
  2. In the IP Reputation tab section, classify the threat categories under allowed list and blocked list.

    Classify IP address threat category

Rate limit

The Rate Limit security check limits network traffic and protects your application from security vulnerabilities and bot attacks. The filter limits traffic by restricting the number of user requests that an application can receive within a timeframe.

The filter uses a rate limit condition that measures the number of requests received within a timeframe. If there are too many requests within a timeframe, the check blocks requests exceed the threshold limit. By doing this, the Citrix App Delivery and Security Service – Citrix Managed protects your application from excess traffic.

Example use case: Rate limiting requests per URL for a ticket booking website Consider a ticket booking website www.adcsvc.example.com that receives huge traffic every 2 minutes. To limit traffic to the website, you can limit the number of requests per URL to 200 for 120 seconds. If there are more than 200 requests received per URL within 120 seconds, then the rate limit security check validation fails, and the check blocks the excess requests per URL.

Enable rate limit protection

Before you configure the rate limit policy you must enable the security check. When disabled, the CADS service does not rate limit traffic to your application.

Configure rate limit policy

Complete the following steps to configure the rate limit policy for enhanced application security.

  1. Navigate to Application > Security Protection > Create New Security Protection > Rate Limit.
  2. In the Rate Limit tab section, click New Policy.
  3. In the Configure Rate Limit Policy page, set the following parameters:

    1. Policy Name. Name of the rate limit policy.
    2. Limit Requests. Logical condition to rate limit traffic.

      1. Server

        1. For overall app. Logical condition to rate limit traffic on the server-side.
        2. Per URL. Logical condition to rate-limit traffic if it matches the pre-defined URL on the server-side.
        3. Per URL matching the pattern. Logical condition to rate-limit traffic only if the incoming request URL exactly matches the pre-defined URL on the server-side.
        4. Matching the URL pattern. Logical condition to rate-limit traffic only if the incoming request URL matches the URL syntax pattern on the server-side.
      2. Client

        1. Per client IP. Logical condition to rate limit traffic based on client IP address.
        2. Per client matching the following client pattern. Logical condition to rate-limit traffic if the response URL matches the predefined URL on the client side.
        3. Matching the client pattern. Logical condition to rate-limit traffic if the response URL matches the predefined client or subnet address.
        4. Per client identified by a specified HTTP header. Logical condition to rate-limit traffic per client identified by a specific HTTP header.
        5. Per client identified by values in an HTTP header. Logical condition to rate-limit traffic per client identified by a specific HTTP header value.
        6. Per client identified by a cookie. Logical condition to rate-limit traffic per client identified by a cookie.
        7. Per client identified by a user agent. Logical condition to rate-limit traffic per client identified by a user agent.
      3. Server and Client

        1. Per client matching the specific URL. Logical condition to rate-limit traffic per client matching exactly the URL.
    3. Maximum requests. Maximum number of requests that is allowed within a time frame.
    4. Timeframe. Maximum time (in seconds) to rate limit traffic.
    5. Subsequent requests are. Action to apply.
    6. Status. Enable or disable rate limit policy configuration.
  4. Click Add Policy.

    Configure rate limit policy

You can view the policy in the Rate Limit summary section.

Rate limit summary view

SQL injection

The SQL injection filter examines the incoming request for SQL Injection attacks. If an SQL attack is detected in the payloads, the security check blocks the request. Use the SQL protection check to secure your web application and prevent SQL injection attacks.

Enable SQL injection protection

Before you configure the SQL injection exception, you must first enable security protection for HTML or JSON content type requests. When disabled, the CADS service does not inspect the traffic for SQL injection attacks. Also, you must toggle the Block action to block requests that contain malicious SQL attacks. When the block action is not selected, CADS service only logs the data.

Enable SQL injection protection

Create an SQL injection exception

An SQL injection attack can occur in several parts of a request. The variants of an SQL injection attack are:

  • Form fields. A basic SQL injection attack can be through a login page where the user provides input. The web application accepts inputs through the page, which pass the user input to the database for processing. If the web application accepts inputs without sanitizing them, an attacker can inject SQL statements through the form fields that can delete, copy, or modify contents in the database.

  • Header. Server variables such HTTP headers can also be vulnerable for SQL injection. If a web application accepts inputs from HTTP headers, fake headers containing arbitrary SQL can inject code into the database.

  • Cookie. Cookies are another vulnerability for SQL injection. This is done by modifying cookies to affect the database queries. Web applications often load cookies and use the data for database operations. A malicious user, or malware deployed on a user’s device, can modify cookies, to inject SQL in an unexpected way into the back-end database.

To avoid false positives and bypass a security check, you can add an SQL injection exception for form fields, header, or cookie values

Complete the following steps to add an exception.

  1. Navigate to Security Protection > SQL Injection > New exception.
  2. Set the following parameters to add an exception for SQL injection protection:

    1. URL Pattern. The URL for which the exception is required. It can be a regular expression. For any URL enter ’.*’.
    2. Field type. The field type for which the exception is required.
    3. Form field names. The form field in which the exception is required. It can be a regular expression.
    4. Status. Enable or disable the SQL injection exception.
  3. Click Add Exception.

    Create an SQL injection exception

    You can view the exception on the SQL Injection tab section.

    SQL injection summary review

Update an SQL injection exception

Complete the following steps to update an SQL injection exception:

  1. Navigate to Applications > Security Protection > SQL Injection.
  2. In the SQL Injection tab section, select an exception and click the pencil icon to edit.
  3. In the Configure SQL injection exception page, edit details and click Update Exception.
  4. You can view the updated exception in the SQL Injection summary section.
  5. Click Update Security Protection.

As a next step, you can configure the Buffer overflow security check. Otherwise, click Deploy.

Buffer overflow

The buffer overflow security check detects if your application receives more input than expected that can cause a buffer overflow on the application server. For example, let us consider the origin server is set to handle a URL length of maximum of 500 characters but if an incoming URL length is 700 characters, the buffer overflow security check validation fails, and it blocks the request. To prevent buffer overflows, the Citrix App Delivery and Security Service – Citrix Managed security check enables you to set the maximum length for request parameters such as URL, cookie, or header value. If the input value for these parameters is longer than the profiled length, then the check blocks the request because it can cause an overflow.

Enable buffer overflow protection

Before you configure the buffer overflow limit, you must enable the security check. When disabled, the Citrix App Delivery and Security Service – Citrix Managed does not inspect the traffic for buffer overflows. Also, you must enable the Block toggle to block requests that can cause a buffer overflow. When the block toggle is not selected, the Citrix App Delivery and Security Service – Citrix Managed only logs the data.

Configure buffer overflow limit

You can prevent the buffer overflow vulnerability by configuring the maximum length for parameters such as URL, cookie, or header length.

  1. Navigate to Application > Security Protection > Create New Security Protection > Buffer Overflow.
  2. In the Buffer Overflow tab section, set the following parameters:

    1. Maximum Container Depth. Enter the maximum allowed nested depth for a JSON element. Requests with container depth greater than the configured value are blocked. Default: 5, minLength: 0, maxLength: 127.
    2. Maximum Document Length. Enter the maximum allowed document length in a JSON request. Requests with document size greater than the configured value are blocked. Default: 20000000, minLength: 0, maxLength: 2147483647.
    3. Maximum Object Key Count. Enter the maximum allowed object key count in a JSON request. Requests with object key count greater that the configured value are blocked. Default: 10000, minLength: 0, maxLength: 2147483647.
    4. Maximum Object Key Length. Enter the maximum allowed length for an object key in a JSON request. Requests with object keys of length greater than the configured value are blocked. Default: 128, minLength: 0, maxLength: 2147483647
    5. Maximum Array Length. Enter the maximum length for an array in a JSON request. Requests with array length greater than the configured value are blocked. Default: 10000, minLength: 0, maxLength: 2147483647.
    6. Maximum String Length. Enter the maximum allowed length for a string in a JSON request. Requests with json string length greater than the configured value are blocked. Default: 1000000, minLength: 0, maxLength: 2147483647.

    Configure buffer overflow limit

As a next step, you can configure Cookie Consistency filter. Otherwise, click Deploy.

The cookie consistency filter examines if the cookie returned by the user matches the cookies set by the website. If a modified value is found, the cookie is stripped from the request before forwarding it to the application server.

Before configuring the cookie consistency security check, you must first enable the feature. When disabled, CADS does not inspect the traffic for cookie consistency attacks. Also, you must toggle the Block action to block requests that contain malicious SQL attacks. If the block action is not selected, CADS only logs the data.

Enable cookie consistency

You can create an exception to prevent blocking legitimate requests or resolve false positives and bypass the security check. Complete the following steps to add an exception.

  1. Navigate to Application > Create a New Security Protection > Cookie consistency > Manage Cookie Consistency.
  2. Set the following parameters to add an exception for cookie consistency:

    1. Cookie Name. Name of the cookie set by the server.
    2. Status. Enable or disable cookie consistency exception.
  3. Click Add Exception.

Configure cookie consistency exception

You can view the exception in the cookie consistency summary section.

Configure cookie consistency exception

Complete the following steps to update a cookie consistency exception:

  1. Navigate to Applications > Create a New Security Protection > Cookie Consistency.
  2. In the Cookie Consistency tab section, select an exception and click the pencil icon to edit.
  3. In the Manage Cookie Consistency page, edit details and click Update Exception.
  4. You can view the updated exception on the Cookie Consistency tab section.

As a next step, you can configure Cross-site Scripting check, Otherwise click Deploy.

Cross-site Scripting

In a Cross-Site Scripting (cross-site scripting) attack, an attacker inserts malicious code into an incoming request that can have huge implications, such as compromising website security or user authentication. Use the cross-site scripting feature to secure your web application and prevent cross-site scripting attacks.

Enable Cross-Site Scripting check

Enable Cross-site Scripting protection

Before you configure the Cross-site Scripting exception, you must first enable the security check for HTML or JSON content type requests. When disabled, the CADS service does not inspect the traffic. Also, you must enable the Block toggle to block requests that contain malicious Cross-site scripting attacks. When the block is not selected, CADS service only logs the data.

Enable cross-site scripting protection

Create a Cross-site Scripting exception

You can add a Cross-site Scripting exception for form field, header, and cookie values to prevent blocking legitimate requests or resolve false positives, and bypass the security check. Complete the following steps to add an exception.

  1. Navigate to Security Protection > Cross-site Scripting > New exception.
  2. Set the following parameters to add the cross-site scripting exception:

    1. URL Pattern. The URL for which the exception is required. It can be a regular expression. For any URL enter ‘. *’.
    2. Field type. The field type for which the exception is required.
    3. Form field names. The form field in which the exception is required. It can be a regular expression.
    4. Status. Enable or disable the cross-site scripting exception.
  3. Click Add Exception.

    Configure cross-site scripting exception

You can view the exception on the cross-site scripting summary section.

Cross-site scripting summary view

Update a Cross-site scripting exception

Complete the following steps to update a Cross-site scripting exception:

  1. Navigate to Applications > Security Protection.
  2. Click Add Security Protection.
  3. In the Add Security Protection slide, select an exception and click the pencil icon to edit.
  4. In the Configure Cross-site Scripting Exception page, edit details and click Update Exception.
  5. You can view the updated exception on the Create new Security Protection page.

Click Next to configure Cookie consistency security protection. Otherwise, click Deploy.

Command Injection 

The command injection security check examines if an incoming request has unauthorized commands that can break the system security or modify the system. If the request has malicious commands, the CADS service blocks the request.

Enable command injection 

Before configuring the command injection security check, enable the feature for HTML and JSON content type requests. When disabled, CADS service does not inspect the traffic for command injection attacks. Also, you must toggle the Block action to block requests that contain unauthorized command attacks. If the block action is not selected, CADS service only logs the data.

Enable command injection 

Create a command injection exception 

You can add an exception for legitimate requests or resolve false positives, and bypass command injection check. Complete the following steps to add an exception.

  1. Navigate to Security Protection > Command Injection > New exception.
  2. Set the following parameters to add a command injection exception:

    1. Exception type. Select a content type to add an exception for command injection check.
    2. URL Pattern. The URL for which the exception is required. Only for JSON content type, the URL is applicable. It can be a regular expression. For any URL enter ‘. *’.
    3. Field Type. Vulnerable field that can be excluded from security check input validation.
      1. Form Field. If the vulnerable field type is selected as form field, then enter the field name.
      2. Header. If the vulnerable field type is selected as header, then enter the header name.
      3. Cookie. If the vulnerable field type is selected as cookie, then enter the cookie name.
    4. Status. Toggle command injection exception status. 
  3. Click Add Exception.

Configure command injection 

You can view the exception in the command injection summary section.

View command injection summary table 

Update a command injection exception 

Complete the following steps to update a command injection exception:  

  1. Navigate to Application > Security Protection. 
  2. Click Add Security Protection. 
  3. In the Add Security Protection slide, select an exception and click the pencil icon to edit.
  4. In the Configure command injection exception page, edit details, and click Update Exception.
  5. You can view the updated exception on the Command Injection tab page.

Cross Site Request Forgery (CSRF)

The Cross Site Request Forgery (CSRF) security check tags each web form sent by a protected website to users with a unique and unpredictable Form ID. When there is an incoming request from the user, the security filter examines the web form to ensure that the supplied Form ID is correct. The security check is applicable only to HTML requests that contain a web form, with or without data.

Enable CSRF

Before configuring the CSRF security check, you must first enable the feature. When disabled, CADS does not inspect the traffic for CSRF attacks. Also, you must toggle the Block action to block requests that contain malicious CSRF attacks. If the block action is not selected, CADS only logs the data.

Create a CSRF exception

You can create a CSRF exception to prevent blocking legitimate requests or resolve false positives and bypass the security check. Complete the following steps to add an exception.

  1. Navigate to Application > Create a New Security Protection > CSRF > New Exception.
  2. Set the following parameters to add an exception for CSRF:

    1. URL Pattern. The URL for which the exception is required. It can be a regular expression. For any URL enter ‘. *’.
    2. Status. Toggle command injection exception status.
  3. Click Add Exception.

CSRF exception

You can view the exception in the CSRF summary section.

CSRF summary section

Update a CSRF exception

Complete the following steps to update a CSRF exception:

  1. Navigate to Applications > Create a New Security Protection > CSRF.
  2. In the CSRF tab section, select an exception and click the pencil icon to edit.
  3. In the Configure CSRF Exception page, edit details and click Update Exception.
  4. You can view the updated exception on the CSRF tab section.

As a next step, you can configure Field Consistency. Otherwise, click Deploy.

Field consistency

The field consistency security check examines web forms returned by a user to a website and verifies if the web forms were modified inappropriately by the client. The security check applies only to HTML requests that contain web forms, with or without data.

Enable field consistency

Before configuring field consistency security check, you must first enable the feature. When disabled, CADS does not inspect the traffic for form field attacks. Also, you must toggle the Block action to block requests that contain malicious attacks. If the block action is not selected, CADS only logs the data.

Enable Field consistency

Create field consistency exception

You can create a field consistency exception to prevent blocking legitimate requests or resolve false positives and bypass the security check. Complete the following steps to add an exception.

  1. Navigate to Application > Create a New Security Protection > Field Consistency > New Exception.
  2. Set the following parameters to add an exception for CSRF:

    1. URL Pattern. The URL for which the exception is required. It can be a regular expression. For any URL enter ‘. *’.
    2. Status. Toggle command injection exception status.
  3. Click Add Exception.

Field consistency exception

You can view the exception on the Field Consistency section.

Field consistency summary page

Update field consistency exception

Complete the following steps to update a Cross-site scripting exception:

  1. Navigate to Applications > Security Protection.
  2. Click Add Security Protection.
  3. In the Add Security Protection slide, select an exception and click the pencil icon to edit.
  4. In the Configure Field Consistency Exception page, edit details, and click Update Exception.

Click Next to configure Signatures. Otherwise, click Deploy.

WAF Signatures

A signature represents a pattern that is a component of a known attack on an operating system, web server, website, XML-based web service, or any other resource. A set of configurable rules offers an easy-to-use security service, applying the power of pattern matching to detect attacks and protect your application against common vulnerabilities and exposures.

Enable WAF signature protection

Before you customize a signature rule, you must enable the security check. When disabled, the Citrix App Delivery and Security Service – Citrix Managed does not inspect the traffic for common vulnerability attacks. Also, enable the Block toggle to block requests with a common vulnerability attack. When the block toggle is not selected, the Citrix App Delivery and Security Service – Citrix Managed only logs data for the selected signature rule.

Manage WAF signatures

The Signature tab section displays a preconfigured list of signatures with new rules added periodically or updates added to old rules. As a user, you might want to customize a signature or list of signatures under a category. To filter signatures, you can select a category and use the search functionality to narrow-down your search.

Categories. Signatures are classified under various categories. You can select a category to view the list of signatures classified under it. For example, selecting web-cgi reduces the table to display signatures that reference web-cgi attack type.

Search. The search functionality enables you to locate a signature based on the category that you have selected. For example, selecting web-cgi as the signature category, you can use the signature attributes to filter signatures that reference this category. Following are the signature attributes and its search operators to filter your search:

  • ID. Unique identifier for a signature. Use the search operator to sort rules based on signature ID.
  • Log string. Log message for a signature. Use the search operator to sort rules based on log string value.
  • Year. The year when the rule was newly added. Use a search operator to sort rules based on a year value.
  • Reference. External references to a signature. Use a search operator to sort rules based on reference.
  • Block. Block toggle to block traffic. Use a search operator to sort rules based on block toggle status.
  • Log. Log toggle to only log data. Use a search operator to sort rules based on log toggle status.

Customize a WAF signature

Complete the following steps to customize a signature:

  1. Navigate to Application > Create a New Security Protection > Signatures.
  2. In the Signature tab section, select signatures and set the following parameters:

    1. Log. Enable log toggle to only log signature violation.
    2. Block. Enable block toggle to block traffic.

    Customize a WAF signature

HTTP security headers

HTTP response headers are used to prevent security attacks on your web application by controlling the browser behavior during application access. In addition to the default headers, the security check enables you to add a security header or delete the Server: Apache/2.4.1 (UNIX) header in the HTTP responder headers for enhanced security protection.

Enable HTTP security header protection

Before you configure the HTTP headers, you must enable the security check. When disabled, the Citrix App Delivery and Security Service – Citrix Managed does not inspect the traffic for HTTP security headers.

Configure default HTTP security header

Complete the following steps to insert a default HTTP header:

  1. Navigate to Application > Security Protection > Create New Security Protection > HTTP Security Headers.
  2. In the HTTP Security Headers tab section, set the following recommended default headers.

    1. X-Frame-Options. Specifies the browser how to behave when rendering a page in <frame>, <iframe>, <embed> or, <object> format. The security header protects the website from clickjacking attacks. There are two directives for X-Frame options – DENY and SAMEORIGIN. If you specify DENY attempts to load frames from both the same sites and other sites will FAIL. If you specify SAMEORIGIN, page loading works from the same website and fails for other websites.

      1. Value. Select directive type as DENY and SAMEORIGIN.
      2. Status. Select the toggle to insert the header when examining the traffic.
      3. Actions. Click the pencil icon to edit a directive.
    2. Content-Security-Policy. Enables administrators to mitigate Cross site script and clickjacking attacks by controlling how the browser loads JavaScript’s images, CSS from different sources. For example, Content-Security-policy: script-src ‘self’ js.example.com. Indicates how JavaScript can be loaded from js.example.com and not from anything else.

      1. Value. Set the source directive value.
      2. Status. Select the toggle to insert the header when examining the traffic
      3. Actions. Click the pencil icon to edit.
    3. X-Content-Type-Options. Specifies the browser that only the MIME types advertised by the original web server in the Content-Type headers must be used. This header protects the website against MIME sniffing vulnerabilities.
    4. Referrer-Policy. Specifies the browser how much referrer information must be included with requests. There are two directives for referrer-policy security header – no-referrer and no-referrer-when-downgrade (default).

      1. Referrer-policy security header – no-referrer. If you specify the no-referrer directive, the Referrer header is omitted, and no referrer information is sent along with the requests.
      2. No-referrer-when-downgrade (default). If you specify the no-referrer-when-downgrade (default) directive, the origin, path, and query string of the URL are sent as a referrer when the protocol security level stays the same (HTTP -> TTP, HTTPS→HTTPS) or improves (HTTP -> HTTPS), but not sent to less secure destinations (HTTPS→HTTP). For “origin” derivative, only the origin of the document is sent as referrer.

        1. Value. Directives type for referrer-policy security header.
        2. Status. Select the toggle to insert the header when examining the traffic
        3. Actions. Click the pencil icon to select a directive.

Configure HTTP Security header

Add an HTTP security header

The Citrix App Delivery and Security Service – Citrix Managed, security protection enables you to add an extra HTTP security header for enhanced security protection. Complete the following steps to add a new HTTP header:

  1. Navigate to Application > Security Protection > Create New Security Protection > HTTP Security Headers.
  2. In the HTTP Security Headers tab section, click Insert Additional Headers.
  3. In the Insert Additional Headers page, set the following parameters.

    1. Header Name. Name of the HTTP security header.
    2. Value. Directive for the security header.
    3. Status. Select the toggle to insert the header when examining the traffic.
  4. Click Add Header.

    Add an HTTP security header

You can view the header on the Additional Headers summary section.

View HTTP security header summary view

Delete an HTTP server header

The Citrix App Delivery and Security Service – Citrix Managed, security protection enables you to delete a server header from the HTTP server-side response. Complete the following steps to delete a header:

  1. Navigate to Application > Security Protection > Create New Security Protection > HTTP Security Headers.
  2. In the HTTP Security Headers tab section, click Delete Headers.
  3. In the Delete Headers page, set the following parameters.

    1. Header Name. Name of the server header to be removed in the HTTP response.
  4. Click Delete Header.

    Delete the HTTP server header

You can view the header on the Delete Headers summary section.

Delete header summary view

Enable cookie consistency protection

Bot signatures

The bot signature security check protects your web application against bot attacks. Bot signatures help in identifying good and bad bots based on request parameters such as user-agent in the incoming request.

Enable bot signature protection

Before you customize a bot signature rule, you must enable the security check. When disabled, the Citrix App Delivery and Security Service – Citrix Managed does not inspect the traffic for bot attacks. Also, enable the Block toggle to block requests with a bot attack. When the block toggle is not selected, the Citrix App Delivery and Security Service – Citrix Managed only logs data for the selected bot rule.

Manage bot signatures

The list of bot signatures is huge and new rules get added and stale ones are removed periodically. As a user, you might want to search for a specific bot signature or list of signatures under a category. To filter signatures easily, the bot signature page provides an enhanced search capability. The search function enables you to find bot rules and customize its property based on one or more bot signature attributes.

Categories. Bot signatures are classified under different categories. You can select a category to view the list of bot signatures classified under it. For example, selecting “Crawler” reduces the table to bot rules that reference Crawler, and it is an easy way to locate Crawler type bot attacks.

Search. The search functionality enables you to locate a bot signature based on the category that is selected. For example, selecting “Crawler” as the bot signature category, you can use the bot signature attributes and its search operators to filter a signature that reference the selected bot category. Following are the bot signature attributes and its search operators to filter your search.

  • Id. Sort bot signatures based on bot rule ID.
  • Name. Sort bot signatures based on rule name.
  • Developer. Sort bot signatures based on the host company publisher.
  • Type. Sort bot signatures based on signature type.
  • Action. Sort bot signatures based on bot action.
  • Log. Sort bot signatures that have logging enabled.
  • Block. Sort bot signatures that have blocking enabled.

Customize a bot signature

Complete the following steps to customize a bot signature:

  1. Navigate to Application > Create a New Security Protection > Bot Signatures.
  2. In the Signature tab section, select signatures and set the following parameters:

    1. Log. Enable or disable log to only log data.
    2. Block. Enable or disable block toggle to block traffic.
    3. Action. Action to apply on bot evaluation. Action types are as follows:

      1. Drop. Drop user request without sending a response.
      2. Reset. Reset client connection by closing it.

    Customize a bot signature

  3. Once you customize a bot signature rule. Click Create New Security Protection.
  4. You can view the security protection profile in the Add Security Protection summary section.
  5. Select the profile and click Add Security Protection.

    Bot signature summary view

In the Deliver an Application page, bind the security profile to a service and click Deploy. This step completes the procedure for application delivery.