Security protection

Citrix App Delivery and Security Service – Citrix Managed edition, provides an intent-based security protection for your web applications and APIs from common exploits and attacks. With the Citrix App Delivery and Security Service – Citrix Managed security protection, you can define your business intent without understanding the complexity of ADC configuration, network, policies, and security configuration that the traffic passes through. In addition to firewall security, the Citrix App Delivery and Security Service – Citrix Managed also provides visibility into security insights that provide real-time monitoring of traffic violations and vulnerabilities.

With a simplified setup, the Citrix App Delivery and Security Service – Citrix Managed saves your time from complex manual configuration and provides threat detection and monitoring of security insights.

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 that might not be detected by signatures alone. 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.

Block action

The block action prevents vulnerabilities from attacking your application. A security check has a block toggle disabled by default. You can enable it if you prefer to block a request that contains a malicious attack. When a block is not selected, the Citrix App Delivery and Security Service – Citrix Managed only logs the data.

Log action

The log action enables you log requests that contain a malicious attack for investigation and analysis of violations details.

Exception (rule)

In security protection, 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, and cookie consistency. These rules are written to bypass security validation for false positives related to Cross-Site Scripting, SQL injection, or cookie consistency.

You can configure an exception to avoid false positives or bypass security checks for the 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 exploits to your web applications.
  • Incoming traffic with cookie consistency attacks to gain access to the legitimate session of the target user.

The Citrix App Delivery and Security Service – Citrix Managed security protection not only enables you to create an exception but also manages exceptions for Cross-site scripting, SQL Injection, and Cookie Consistency security checks through the Citrix App Delivery and Security Service – Citrix Managed GUI or API interface. Based on the exception that is configured, the corresponding action is applied to the traffic.

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 security checks

Citrix App Delivery and Security Service – Citrix Managed security protection provides the following features that secure your application delivery on the cloud.

  1. Allow and block list. Inspects the incoming traffic with rules to allow or block the client’s access to web application resources. The rules are defined based on parameters such as IP address, subnet, or HTTP request headers.
  2. SQL injection protection. Inspects HTTP or HTTPS requests and blocks SQL injection attacks that affect your web applications.
  3. Cross-site scripting protection. Inspects HTTP or HTTPS requests and blocks invalidated cross-site scripting scripts causing malicious activities.
  4. Buffer overflow protection. Inspects if an incoming traffic is causing buffer overflow on the web server. If the service detects a URL, a cookie, or a header longer than the specified maximum length, the request is blocked because of the buffer overflow attack.
  5. Geo blocking. Restricts unauthorized access based on user’s geographical location.
  6. IP reputation. Blocks traffic coming from an IP address with a bad reputation score.
  7. Rate Limit. Limits the amount of network traffic. For example, if there is an API that limits the number of incoming requests as 100, then any additional requests are blocked. Rate limiting controls traffic flow based on client IP address, client subnet, URL, or URL pattern, and HTTP headers.
  8. HTTP Security Headers. Prevents security attacks on the web application by controlling the browser behavior during application access.
  9. 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 traffic, you can add an exception.
  10. 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 does not match a signature pattern. By default, all signatures are enabled.
  11. Bot signatures. A list of bot signatures 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 does not match a bot pattern. By default, all bot signatures are enabled.

Before you enable a security check, you must create a security protection profile or add a security profile to your application.

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 Add Security Protection.
  3. In the Add Security Protection slide, select a security protection profile and click Add Security Protection.

    Add Citrix App Delivery and Security security protection profile

  4. Bind the security protection to a service and click Apply.

    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. As a next step, 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 Add Security Protection.
  3. In the Add Security Protection slide, click Create New Security Protection.
  4. In the Create New Security Protection page, enter a name and configure the following security features:

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

    You can view the newly created security protection profile on the Add Security Protection slider.

    Create a security protection profile

  6. Select the security protection and click Add Security Protection.
  7. Bind the security protection to a service and click Apply.

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 Add Security Protection.
  3. In the Add Security Protection slide, select a security protection and click the pencil icon to edit.
  4. In the Update Security Protection page, edit details and click Update Security Protection.
  5. Select the modified security protection and click Add Security Protection.
  6. Bind the security protection to a service and click Apply.

    Update a security protection profile

You can view the updated security protection on the Add Security Protection slider.

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 the SQL Injection 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.

SQL injection protection

The SQL injection protection 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 injection filter to secure your web application and prevent SQL injection attacks.

Prerequisite

Before you begin, verify if:

  1. SQL Injection toggle is enabled.
  2. Block toggle is enabled for blocking SQL injection attacks or disabled for only logging data.

Enable SQL injection protection

Before you configure the SQL injection exception, you must first enable the security check. When disabled, the Citrix App Delivery and Security Service – Citrix Managed does not inspect the traffic for SQL injection attacks. Also, you must enable the Block toggle to block requests that contain malicious SQL attacks. When the block toggle is not selected, the Citrix App Delivery and Security Service – Citrix Managed only logs the data.

Enable SQL injection protection

Create an SQL injection exception

You can add an SQL injection exception for form fields, 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 > 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 Cross-Site Scripting security check. Otherwise, click Deploy.

Cross-site scripting protection

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

Prerequisite

Before you begin, verify if:

  1. Cross-site scripting security protection toggle is enabled.
  2. Block toggle must be enabled for blocking Cross-site scripting attacks.

Enable Cross-site scripting protection

Before you configure the Cross-site scripting exception, you must first enable the security check. When disabled, the Citrix App Delivery and Security Service – Citrix Managed 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, the Citrix App Delivery and Security Service – Citrix Managed 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 Buffer Overflow security protection. Otherwise, click Deploy.

Buffer overflow security protection

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.

Prerequisite

Before you begin, verify if:

  1. Buffer Overflow toggle is enabled.
  2. Block toggle must be enabled for blocking buffer overflow attacks.

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 URL length.  Maximum allowed length for a request URL. The default value is set as 1024 bytes.
    2. Maximum cookie length. Maximum allowed cookie length in a request. The default maximum limit is set as 4096 bytes.
    3. Maximum header length. Maximum allowed header length in a request. The default value is 4096 bytes.

    Configure buffer overflow limit

As a next step, you can configure Geo blocking filter. Otherwise, click Deploy.

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.

Prerequisite

Before you begin, verify if the Geo Blocking toggle is enabled.

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, the rate limit security check validation fails, and the excess requests per URL are blocked.

Prerequisite

Before you begin, verify if the Rate Limit toggle is enabled.

Enable rate limit protection

Before you configure the rate limit policy you must enable the security check. When disabled, the Citrix App Delivery and Security Service – Citrix Managed 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

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.

Prerequisite

Before you begin, verify if the HTTP Security Headers toggle is enabled.

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. Strict-Transport-Security. Specifies the browser not to receive any communication sent over HTTP to the specified domain, instead send all communication over HTTPS. This security header protects the website from HTTPS click-through prompts on browsers. There are two directives for strict transport security – includeSubDomains and preload. If you specify the includeSubDomains parameter, the rule applies to all website subdomains as well. If you specify preload, the rule applies to a HSTS preload service. By following the guidelines and successfully submitting your domain, browsers never connect to your domain using an insecure connection.

      1. Value. Set values for the following directives

        1. Include Sub Domains. Protects your application including all website subdomains from all HTTPS click-through prompts.
        2. max-age (seconds). The maximum time the browser must know that a site is only to be accessed using the HTTPS.
        3. Preload. Protects your application with HSTS preload service.
      2. Status. Select the toggle to insert the header when examining the traffic
      3. Actions. Click the pencil icon to edit a directive.
    3. 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.
    4. 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.
    5. Referrer-Policy. Specifies the browser how much referrer information must be included with requests. There are two directives for the referrer-policy security header – no-referrer and no-referrer-when-downgrade (default). If you specify the no-referrer directive, the Referrer header is omitted, and no referrer information is sent along with the requests. If you specify the no-referrer-when-downgrade directive, the origin, path, and query string of the URL are sent as a referrer when the protocol security level stays the same (HTTP to HTTP, HTTPS to HTTPS) or improves (HTTP to HTTPS), but not sent to less secure destinations (HTTPS to HTTP). For the origin derivative, only the origin of the document is sent as referrer. For example, a document at https://example.com/page.html sends the referrer https://example.com/. For the origin-when-cross-origin derivative, only the origin, path, and query string are sent when performing a same-origin request and only the document origin is sent for other cases. For the same origin directive, a referrer is sent for same-site origins and cross-origin requests sends no referrer information. For the strict-origin directive, only the origin of the document is sent as the referrer when the protocol security level stays the same (HTTPS to HTTPS) but does not send it to a less secure destination (HTTPS to HTTP). For the strict-origin-when-cross-origin directive, only the origin, path, and query string are sent when performing a same-origin request and only send the origin when the protocol security level stays the same when performing a cross-origin request (HTTPS to HTTPS) and send no header to any less-secure destinations.

      1. Value. Directive 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

The Cookie Consistency security check examines the cookie returned by a browser, to verify if it matches the cookie set by the website. If a modified cookie is found, it is stripped from the request before the request is forwarded to the web server.

Prerequisite

Before you begin, verify if:

  1. Cookie consistency security protection toggle is enabled.
  2. Block toggle must be enabled for blocking consistency attacks or disabled for only logging data.

You must first enable the feature to apply for security protection. When disabled, the cookie attacks. Also, you must enable the Block toggle to block requests that contain a modified cookie. When the block toggle is not selected, the Citrix App Delivery and Security service only logs the data.

Enable cookie consistency protection

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

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

Cookie consistency summary view

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 Signatures. Otherwise, click Deploy.

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.

Prerequisite

Before you begin, verify if the Signature toggle is enabled.

Enable 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 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 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 signature

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.

Prerequisite

Before you begin, verify if the Bot signature toggle is enabled.

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.