Application Firewall Test

ADC 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 ADC 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 tracks the network traffic flowing through the Application Firewall, and 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.

Target of the test : An ADC VPX/MPX

Agent deploying the test : A remote agent

Outputs of the test : One set of results for the ADC 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.

NetScaler Username and NetScaler Password

To monitor a ADC device, the eG agent should be configured with the credentials of a user with read-only privileges to the target ADC device. Specify the credentials of such a user in the NetScaler Username and NetScaler Password text boxes.

SSL

The eG agent collects performance metrics by invoking NITRO (ADC Interface Through Restful interfaces and Objects) APIs on the target ADC device. Typically, the NITRO APIs can be invoked through the HTTP or the HTTPS mode. By default, the eG agent invokes the NITRO APIs using the HTTPS mode. This is why, the SSL flag is set to Yes by default. If the target ADC device is not SSL-enabled, then the NITRO APIs can be accessed through the HTTP mode only. In this case, set the SSL flag to No.

Measurements made by the test

Measurement

Description

Measurement Unit

Interpretation

Data received

Indicates the amount of data received for requests by this Application firewall during the last measurement period.

MB

 

Data transmitted

Indicates the amount of data transferred for responses received by this Application firewall during the last measurement period.

MB

 

Requests

Indicates the number of HTTP/HTTPS requests sent to the web servers through this Application firewall during the last measurement period.

Number

 

Responses

Indicates the number of HTTP/HTTPS responses sent by the web servers through this Application firewall during the last measurement period.

Number

 

Aborts

Indicates the number of incomplete HTTP/HTTPS requests aborted by the client before this Application Firewall completes processing during the last measurement period.

Number

A high value for this measure could warrant an investigation.

Redirects

Indicates the number of HTTP/HTTPS requests redirected by this Application Firewall to a different web page or web server during the last measurement period.

Number

 

Long term average response time

Indicates the average backend response time of the Application firewall since reboot.

Secs

Ideally, this value should be low.

Recent average response time

Indicates the average backend response time of this Application firewall over the last 7 seconds.

Secs

Ideally, this value should be low.

Start URL

Indicates the number of Start URL security check violations detected by this Application firewall during the last measurement period.

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 this Application firewall during the last measurement period.

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.

Referer header

Indicates the number of Referrer Header security check violations detected by this Application firewall during the last measurement period.

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.

Buffer overflow

Indicates the number of buffer overflows detected by this Application firewall during the last measurement period.

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 ADC 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.

Cookie consistency

Indicates the number of Cookie Consistency security check violations detected by this Application firewall during the last measurement period.

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 during the last measurement period.

 

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.

HTML cross-site scripting

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

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.

HTML SQL injection

Indicates the number of HTML sql injection security check violation detected by this Application firewall during the last measurement period.

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.

Field format

Indicates the number of field format security check violation detected by the Application firewall during the last measurement period.

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.

Field consistency

Indicates the number of Form Field Consistency security check violations detected by this Application firewall during the last measurement period.

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.

Credit card

Indicates the number of credit card security check violations detected by this Application firewall during the last measurement period.

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.

Safe object

Indicates the number of safe object security check violations detected by this Application firewall during the last measurement period.

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.

Signature violations

Indicates the number of signature security check violations detected by the Application firewall during the last measurement period.

Number

The Application Firewall Signatures function provides specific, configurable rules that protect your Web sites against known attacks. When properly configured, the signatures may provide all the protection that a simple Web site needs. They also provide a good level of immediate protection for more complex Web sites, allowing you to implement that protection without delay while you configure additional protections as needed.

XML format

Indicates the number of XML format security check violations detected by this Application firewall during the last measurement period.

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.

XML denial of service

Indicates the number of XML Denial-of-Service security check violations detected by this Application firewall during the last measurement period.

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.

XML message violations

Indicates the number of XML message validation security check violations detected by this Application firewall during the last measurement period.

Number

The XML Message Validation check examines requests that contain XML messages to ensure that they are valid. If a request contains an invalid XML message, the Application Firewall blocks the request. The purpose of the XML Validation check is to prevent an attacker from using specially-constructed invalid XML messages to breach security on your application.

Web services interoperability

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

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 SQL injection

Indicates the number of XML SQL Injection security check violations detected by this Application firewall during the last measurement period.

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 scripting

Indicates the number of XML Cross-site Scripting security check violations detected by this Application firewall during the last measurement period.

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.

XML attachment

Indicates the number of XML Attachment security check violations detected by this Application firewall during the last measurement period.

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 fault violations

Indicates the number of XML Soap Fault Filtering security check violations detected by this Application firewall during the last measurement period.

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.

XML generic violations

Indicates the number of requests returning XML generic error from the backend server through this Application firewall during the last measurement period.

Number

 

Total violations

Indicates the total number of security check violations detected by this Application firewall during the last measurement period.

Number

This is a good measure of how secure your environment is.

HTTP client errors (4xx)

Indicates the number of requests returning HTTP 4xx error from the backend server during the last measurement period.

Number

The 4xx codes are intended for cases in which the client seems to have erred. Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request.

A high value for either of these measures is a cause for concern, and would require scrutiny.

HTTP server errors (5xx)

Indicates the number of requests returning HTTP 5xx error from the backend server during the last measurement period.

Number