- PCRE Character Encoding Format
- Whitehat WASC Signature Types for WAF Use
- Streaming Support for Request Processing
- Trace HTML Requests with Security Logs
- Application Firewall Support for Cluster Configurations
The Citrix application firewall now uses request side streaming, which results in a significant performance boost. Instead of buffering the entire request before processing it, the application firewall now looks at the incoming data, field by field, to inspect the input of each field for any configured security check violation (SQL, XSS, Field Consistency, Field Formats, etc.). As soon as the processing of the data for a field is completed, it is forwarded to the backend while the evaluation continues for the remaining fields. This significantly improves the processing time specially when handling large posts where the forms have large number of fields.
Although the streaming process is transparent to the users, minor configuration adjustments are required due to the following changes:
RegEx Pattern Match: RegEx pattern match is now restricted to 4K for contiguous character string match.
Field Name Match: Application firewall learning engine can only distinguish the first 128 bytes of the name for learning. If a form has multiple fields with names that have identical string match for the first 128 bytes, the learning engine may not be able to distinguish between them. Similarly, the deployed relaxation rule might inadvertently relax all such fields.
Removing white spaces, percent decoding, unicode decoding, and charset conversion which is done during canonicalization is carried out prior to security check inspection. The 128 byte limit is applicable to the canonicalized representation of the field name in UTF-8 character format. The ASCII characters are 1 byte but the UTF-8 representation of the characters in some international languages may range from 1-4 bytes. If each character in the name takes 4 bytes when converted to UTF-8 format, only first 32 characters in the name may be distinguished by the learned rule for such a language.
XSS/SQL Transform: Raw data is used for transformation because the SQL special characters ( single quote('), backslash (\), and semicolon (;)), and XSS tags ((<) and(>)) are same in all languages and do not need canonicalization of data. All representations of these characters, such as HTML entity encoding, percent encoding, or ASCII are evaluated for transform operation.
The application firewall no longer inspects both the attribute name and value for the XSS transform operation. Now only XSS attribute names are transformed when streaming is engaged.
Processing XSS Tags: As part of the streaming changes in 10.5.e build onwards, the application firewall processing of the Cross-site Scripting tags has changed. In earlier releases, presence of either open bracket (<), or close bracket (>), or both open and close brackets (<>) was flagged as Cross-site Scripting Violation. The behavior has changed in 10.5.e build onwards. Presence of only the open bracket character (<), or only the close bracket character (>) is no longer considered as an attack. It is when an open bracket character (<) is followed by a close bracket character (>), the Cross-site scripting attack gets flagged. Both characters must be present in the right order (< followed by >) to trigger Cross-site scripting violation.
Change in SQL violation log Message: As part of the streaming changes in 10.5.e build onwards, we now process the input data in blocks. RegEx pattern matching is now restricted to 4K for contiguous character string matching. With this change, the SQL violation log messages might include different information compared to the earlier builds. The keyword and special character in the input could be separated by a large number of bytes. We now keep track of the SQL keywords and special strings when processing the data, instead of buffering the entire input value. In addition to the field name, the log message now includes the SQL keyword, or the SQL special character, or both the SQL keyword and the SQL special character, as determined by the configured setting. The rest of the input is no longer included in the log message, as shown in the following example:
In 10.5, when the application firewall detects the SQL violation, the entire input string might be included in the log message, as shown below:
SQL Keyword check failed for field text=\"select a name from testbed1\;\\(\;\\)\".*\<blocked\>
In 11.0, we log only the field name, keyword and special character (if applicable) in the log message, as shown below:
SQL Keyword check failed for field text="select(;)" <blocked>
This change is applicable to requests that contain application/x-www-form-urlencoded, or multipart/form-data, or text/x-gwt-rpc content-types. Log messages generated during processing of JSON or XML payloads are not affected by this change.
RAW POST Body: The security check inspections are always done on RAW POST body.
Form ID: The application firewall inserted “as_fid” tag, which is a computed hash of the form, will no longer be unique for the user session. It will now have an identical value for a specific form irrespective of the user or the session.
Charset: If a request does not have a charset, the default charset specified in the application profile is used when processing the request.
Counters with prefix “se_” and “appfwreq_” are added to track the streaming engine and the application firewall streaming engine request counters respectively.
nsconsmg -d statswt0 -g se_err_
nsconsmg -d statswt0 -g se_tot_
nsconsmg -d statswt0 -g se_cur_
nsconsmg -d statswt0 -g appfwreq_err_
nsconsmg -d statswt0 -g appfwreq_tot_
nsconsmg -d statswt0 -g appfwreq_cur_
_err counters: indicate the rare event which should have succeeded but failed due to either memory allocation problem or some other resource crunch.
_tot counters: ever increasing counters.
_cur counters: counters indicating current values that keep changing based on usage from current transactions.
Calculating the Cookie length: In release 10.5.e (in a few interim enhancement builds prior to 59.13xx.e build) as well as in the 11.0 release (in builds prior to 65.x), application firewall processing of the Cookie header was changed. In those releases, every cookie is evaluated individually, and if the length of any one cookie received in the Cookie header exceeds the configured BufferOverflowMaxCookieLength, the Buffer Overflow violation is triggered. As a result of this change, requests that were blocked in 10.5 and earlier release builds might be allowed, because the length of the entire cookie header is not calculated for determining the cookie length. In some situations, the total cookie size forwarded to the server might be larger than the accepted value, and the server might respond with "400 Bad Request".
Note that this change has been reverted. The behavior in the 10.5.e ->59.13xx.e and subsequent 10.5.e enhancement builds as well as in the 11.0 release 65.x and subsequent builds is now similar to that of the non-enhancement builds of release 10.5. The entire raw Cookie header is now considered when calculating the length of the cookie. Surrounding spaces and the semicolon (;) characters separating the name-value pairs are also included in determining the cookie length.