Application Firewall Violations Test

NetScaler protects against a wide variety of threats with integrated security capabilities (like Application firewall) that protect applications resources, augmenting existing network-layer security protections. The NetScaler Application Firewall secures web applications, prevents inadvertent or intentional disclosure of confidential information and aids in compliance with information security regulations such as PCI-DSS.

This test reports the different types of security check violations that have been detected by the Application Firewall. The statistics reported by this test thus serve as a good measure of the efficiency of the Application Firewall.

For this test to run and report metrics, the NetScaler appliance should be configured to create a Syslog file in a remote Syslog server, where the details of all interactions with the NetScaler appliance will be logged. To know how to configure a remote Syslog server for the use of the NetScaler appliance, refer to Creating a Syslog file in a remote Syslog server topic.

This test is disabled by default. To enable the test, follow the Agents -> Tests -> Enable/Disable menu sequence in the eG administrative interface, pick Citrix NetScaler VPX/MPX as the Component type, select Performance as the Test type, choose this test from the list of disabled tests list, and click on the < button.

Target of the test : A NetScaler VPX/MPX

Agent deploying the test : A remote agent

Outputs of the test : One set of results for the NetScaler appliance being monitored.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed

Host

The IP address of the host for which the test is being configured.

Port

The port at which the host listens. By default, this is NULL.

Log File Path

This test reports metrics by parsing a Syslog file. Specify the full path to the Syslog file here.

Search String

By default, the Syslog file may contain information relating to a number of servers that are inter linked with the target NetScaler appliance. In order to obtain the metrics of the target NetScaler appliance alone, specify the hostname or the IP address of the target NetScaler appliance for which the logs are to be read from the syslog file, in the Search String text box. Using this search string the information in the Syslog file may be parsed and metrics may be collected.

Search String Index

Here, specify the cursor position after which the eG agent should search for the specified Search String (or the position upto which the eG agent should ignore while searching for the specified Search String) in the syslog file. For example, if the specified Search String appears in the syslog file at the 17th position, then you may need to specify the Search String as 16.

DD Frequency

Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Buffer overflow

Indicates the number of buffer overflows detected by the Application firewall.

Number

The buffer overflow might result due to any of the following reasons:

  1. The problem arises when there is a slow Web logging client and relatively smaller chunks of data are sent from the circular buffer. With slow clients, there can be a condition when the writing of the new transactions to the buffer is much faster than the data sent from the buffer to the client. The static buffer might get circled and overwritten with new transactions before the old data is sent to the client. This results in buffer overflow, which results in loss of logging data.
  2. The buffer overflow might also happen due to network congestion between the Web logging client and the NetScaler appliance.

To overcome the buffer overflow, you can increase the value of the buffer size. This can delay the buffer overflow condition. However, it starts again if the processing speed of the client does not match to the rate at which the data is written. The slow processing speed of the client inhibits the speed at which the data is sent to the Web logging client. You can expect some instances of buffer overflow under very high traffic conditions.

If the buffer value increases continuously, then consider increasing the processing speed and the RAM of the client. Additionally, check if network congestion is preventing the client from reading data smoothly.

Field consistency

Indicates the number of Form Field Consistency security check violations detected by the Application firewall.

Number

The Form Field Consistency check examines the web forms returned by users of your web site, and verifies that the web form was not modified inappropriately by the client. This check applies only to HTML requests that contain a web form, with or without data. It does not apply to XML requests.

The Form Field Consistency check prevents clients from making unauthorized changes to the structure of the web forms on your web site when they are filling out a web form and submitting data by using that form. It also ensures that the data a user submits meets the HTML restrictions for length and type, and that data in hidden fields is not modified. This prevents an attacker from tampering with a web form and using the modified form to gain unauthorized access to web site, redirect the output of a contact form that uses an insecure script and thereby send unsolicited bulk email, or exploit a vulnerability in your web server software to gain control of the web server or the underlying operating system. Web forms are a weak link on many web sites and attract a wide range of attacks.

Start URL

Indicates the number of Start URL security check violations detected by the Application firewall.

Number

A URL that a user accesses must be explicitly listed as a Start URL. If it is not, the Citrix Application Firewall software blocks the request.

By default, the Citrix Application Firewall blocks the direct access to the URLs of the Web applications. You must define the URLs you want to allow the users to access directly. Such URLs include the Web application home page, error page of the Web application; any page that you expect that the user might bookmark, and is allowed to bookmark, and any Web page that can be included in another Web site.

Deny URL

Indicates the number of Deny URL security check violations detected by the Application firewall.

Number

The Deny URL check examines and blocks connections to URLs that are commonly accessed by hackers and malicious code. This check contains a list of URLs that are common targets of hackers or malicious code and that rarely if ever appear in legitimate requests. You can also add URLs or URL patterns to the list. The Deny URL check prevents attacks against various security weaknesses known to exist in web server software or on many web sites.

The Deny URL check takes priority over the Start URL check, and thus denies malicious connection attempts even when a Start URL relaxation would normally allow a request to proceed.

XML SQL injection

Indicates the number of XML SQL Injection security check violations detected by the Application firewall.

Number

The XML SQL Injection check examines both the headers and the bodies of user requests for possible XML SQL Injection attacks. If it finds injected SQL, it blocks the request.

To prevent misusing the scripts on your protected web services to breach security on your web services, the XML SQL Injection check blocks scripts that violate the same origin rule, which states that scripts should not access or modify content on any server but the server on which they are located. Any script that violates the same origin rule is called a cross-site script, and the practice of using scripts to access or modify content on another server is called XML SQL Injection. The reason XML SQL Injection is a security issue is that a web server that allows XML SQL Injection can be attacked with a script that is not on that web server, but on a different web server, such as one owned and controlled by the attacker.

Unfortunately, many companies have a large installed base of Javascript-enhanced web content that violates the same origin rule. If you enable the XML SQL Injection check on such a site, you have to generate the appropriate exceptions so that the check does not block legitimate activity. In addition, to prevent blocking of legitimate requests, this check ignores cookies that were set by the server, even if they contain elements that the Cookie Consistency check would otherwise block.

XML cross-site script

Indicates the number of XML Cross-site Scripting security check violations detected by the Application firewall.

Number

The XML Cross-Site Scripting check examines both the headers and the bodies of user requests for possible cross-site scripting attacks. If it finds a possible cross-site scripting attack, it blocks the request.

To prevent misuse of the scripts on your protected web services to breach security on your web services, the XML Cross-Site Scripting check blocks scripts that violate the same origin rule, which states that scripts should not access or modify content on any server but the server on which they are located. Any script that violates the same origin rule is called a cross-site script, and the practice of using scripts to access or modify content on another server is called cross-site scripting. The reason cross-site scripting is a security issue is that a web server that allows cross-site scripting can be attacked with a script that is not on that web server, but on a different web server, such as one owned and controlled by the attacker.

Unfortunately, many companies have a large installed base of Javascript-enhanced web content that violates the same origin rule. If you enable the XML Cross-Site Scripting check on such a site, you have to generate the appropriate exceptions so that the check does not block legitimate activity. In addition, to prevent blocking of legitimate requests, this check ignores cookies that were set by the server, even if they contain elements that the Cookie Consistency check would otherwise block.

SQL injection

Indicates the number of HTML sql injection security check violation detected by the Application firewall.

Number

The HTML SQL Injection check provides special defenses against injection of unauthorized SQL code that might break security. It examines both the headers and the POST bodies of requests for injected SQL code. If the application firewall detects unauthorized SQL code in a user request, it either transforms the request, to render the SQL code inactive, or blocks the request.

Many web applications have web forms that use SQL to communicate with relational database servers. Often, the scripts that pass web form information to the database do not validate the information provided by the user before sending it to the database. Malicious code or a hacker can use the insecure web form to send SQL commands to the web server.

Cookie consistency

Indicates the number of Cookie Consistency security check violations detected by the Application firewall.

Number

The Cookie Consistency check examines cookies returned by users, to verify that they match the cookies that your web site set for that user. If a modified cookie is found, it is stripped from the request before the request is forwarded to the web server. You can also configure the Cookie Consistency check to transform all of the server cookies that it processes, by encrypting the cookies, proxying the cookies, or adding flags to the cookies. This check applies to requests and responses.

An attacker would normally modify a cookie to gain access to sensitive private information by posing as a previously authenticated user, or to cause a buffer overflow. The Buffer Overflow check protects against attempts to cause a buffer overflow by using a very long cookie. The Cookie Consistency check focuses on the first scenario.

CSRF form tag

Indicates the number of Cross Site Request Forgery (CSRF) security check violations detected by this Application firewall.

Number

The CSRF Form Tagging check tags each web form sent by a protected web site to users with a unique and unpredictable FormID, and then examines the web forms returned by users to ensure that the supplied FormID is correct. This check protects against Cross Site Request Forgery (CSRF) attacks. This check applies only to HTML requests that contain a web form, with or without data. It does not apply to XML requests.

The CSRF Form Tagging check prevents attackers from using their own web forms to send high volume form responses with data to your protected web sites. This check requires relatively little CPU processing capacity compared to certain other security checks that analyze web forms in depth. It is therefore able to handle high volume attacks without seriously degrading the performance of the protected web site or the application firewall itself.

Field format

Indicates the number of field format security check violation detected by the Application firewall.

Number

The Field Formats check verifies the data that users send to your web sites in a web form. It examines both the length and type of data to ensure that it is appropriate for the form field in which it appears. If the application firewall detects inappropriate web form data in a user request, it blocks the request. This check applies to HTML requests only. It does not apply to XML requests.

By preventing an attacker from sending inappropriate web form data to your web site, the Field Formats check prevents certain types of attacks on your web site and database servers. For example, if a particular field expects the user to enter a phone number, the Field Formats check examines the user’s response to ensure that the data matches the format for a phone number. If a particular field expects a first name, the Field Formats check ensures that the data in that field is of a type and length appropriate for a first name. It does the same thing for each form field that you configure it to protect.

Credit card

Indicates the number of credit card security check violations detected by the Application firewall.

Number

The Credit Card check provides special handling for credit card numbers. A Webapplication does not usually send a credit card number in a response to a user request, even when the user supplies a credit card number in the request. The Application Firewall examines Web server responses, including headers, for credit card numbers. If it finds a credit card number in the response, and the administrator has not configured it to allow credit card numbers to be sent, it responds in one of two ways:

  1. It blocks the response.
  2. It replaces all but the final group of digits in the credit card with x’s. For example, a credit card number of 9876-5432-1234-5678 would be rendered, xxxx-xxxx-xxxx-5678.

The Credit Card check prevents attackers from exploiting a security flaw in your Web server software or on your Web site to obtain credit card numbers of your customers. If your Web sites do not have access to credit card information, you do not need to configure this check. If your Web sites do have access to credit card information, such as via a shopping cart application, or your Web sites have access to back-end database servers that contain customer credit card numbers, you should configure protection for each type of credit card that you accept.

XML format

Indicates the number of XML format security check violations detected by this Application firewall.

Number

The XML Format check examines the XML format of incoming requests, and blocks those requests that are not well formed, or that do not meet the criteria in the XML specification for properly-formed XML documents. Some of those criteria are:

  1. An XML document must contain only properly-encoded Unicode characters that match the Unicode specification.
  2. No special XML syntax characters—such as “<”, “>” and "&"—can be included in the document except when used in XML markup.
  3. All begin, end, and empty-element tags must be correctly nested, with none missing or overlapping
  4. XML element tags are case-sensitive; all beginning and end tags must match exactly.
  5. A single root element must contain all the other elements in the XML document.

A document that does not meet the XML well-formedness criteria does not meet the definition of an XML document. Strictly speaking, it is not XML. However, not all XML applications and web services enforce the well-formedness standard, and not all handle poorly-formed or invalid XML correctly. Inappropriate handling of a poorly-formed XML document can cause security breaches. The purpose of the XML Format check is to prevent a malicious user from using a poorly-formed XML request to breach security on your XML application or web service.

Cross-site script

Indicates the number of html cross-site scripting attacks detected by this Application firewall.

Number

A cross-site scripting attack (XSS), sends a web application an unvalidated script that activates when it is read by the browser or application to steal user identities, hijack user sessions, poison cookies, redirect users to malicious web sites, access restricted sites and even launch false advertisements. Application Firewall has dynamic context sensitive XSS attack protections that looks for anything that looks like an HTML tag and checks against allowed HTML attributes and tags to detect XSS attacks. Custom XSS patterns can be stored to modify this default list of tags and attributes. Both HTML and XML payloads are inspected. Field format protection and form field consistency is included.

Referer header

Indicates the number of Referrer Header security check violations detected by the Application firewall.

Number

The Start URL check contains a parameter called Referer Header, which if configured, tells the Application Firewall to verify that the Referer header in a request that contains Web form data comes from your protected Web server rather than from another Web site. This verifies that your Web site, rather than an outside attacker, is the source of that Web form. This protects against cross-site request forgeries (CSRF) without requiring form tagging, which is more CPU-intensive than header checks.

Safe object

Indicates the number of safe object security check violations detected by the Application firewall.

Number

The Safe Object check provides user-configurable protection for sensitive business information, such as customer numbers, order numbers, and country- or region-specific telephone numbers or postal codes. A user-defined regular expression or custom plug-in tells the Application Firewall the format of this information, and defines the rules to be used to protect it. If the Application Firewall detects a string in a user request that matches a safe object definition, depending on how you configured that particular Safe Object rule, it either blocks the response, masks the protected information, or removes the protected information from the response before sending it to the user.

XML DOS

Indicates the number of XML Denial-of-Service security check violations detected by the Application firewall.

Number

The XML Denial of Service (XML DoS or XDoS) check examines incoming XML requests to determine whether they match the characteristics of a denial-of-service (DoS) attack, and blocks those requests that do. The purpose of the XML DoS check is to prevent an attacker from using XML requests to launch a denial-of-service attack on your server or application.

WSI

Indicates the number of Web Services Interoperability (WS-I) security check violations detected by the Application firewall.

Number

The Web Services Interoperability (WS-I) check examines both requests and responses for adherence to the WS-I standard, and blocks those requests and responses that do not adhere to this standard. The purpose of the WS-I check is to block requests that might not interact with other XML appropriately. An attacker can use inconsistencies in interoperability to launch an attack on your XML application.

XML attachments

Indicates the number of XML Attachment security check violations detected by the Application firewall.

Number

The XML Attachment check examines incoming requests for malicious attachments, and it blocks those requests that contain attachments that might breach applications security. The purpose of the XML Attachment check is to prevent an attacker from using an XML attachment to breach security on your server.

SOAP faults

Indicates the number of XML Soap Fault Filtering security check violations detected by the Application firewall.

Number

The XML SOAP Fault Filtering check examines responses from your protected web services and filters out XML SOAP faults. This prevents leaking of sensitive information to attackers.

Policy hits

Indicates the number of policy hit violations detected by the Application firewall.

Number

 

XML Generic

Indicates the number of requests returning XML generic error from the backend server through the Application firewall.

Number