Note: This feature is available in NetScaler release 10.5.e.
Web servers following Google Web Toolkit (GWT) Remote Procedure Call (RPC) mechanisms can be secured by the NetScaler application firewall without a need for any specific configuration to enable the GWT support.
For popular websites that use GWT, see
The following example shows a valid payload for a GWT request:
5|0|8|http://localhost:8080/test/|16878339F02B83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String|java.lang.Integer| myInput1|java.lang.Integer/3438268394|1|2|3|4|2|5|6|7|8|1|
The request can be divided into three parts:
a) Header: 5|0|8|
The first 3 digits “5|0|8|” in the above request, represent “version, subversion, and size of table”, respectively. These must be positive integers.
b) String Table:
http://localhost:8080/test/|16878339F02B83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String|java.lang.Integer|myInput1| java.lang.Integer/3438268394|
This is the Request URL. It should not contain the query part, because the GET method is not allowed.
Unique HEX identifier. A request is considered malformed if this string has non-hex characters.
Service Class name
Service method name
Data-types and data. Non-primitive data-types are specified as
c) Payload: 1|2|3|4|2|5|6|7|8|1|
The payload consists of references to the elements in the string table. These integer values cannot be larger than the number of elements in the string table.
The application firewall understands and interprets GWT RPC requests, inspects the payload for security check violations, and takes specified actions.
The application firewall headers and cookies checks for GWT requests are similar to those for other request formats. After appropriate URL decoding and charset conversion, all the parameters in the string table are inspected. The GWT request body does not contain field names, just the field values. The input values can be validated against the specified format by using the application firewall Field Format check, which can also be used to control the length of the input. The Cross-site Scripting and SQL Injection attacks in the inputs can be easily detected and thwarted by the application firewall.
Example of a GWT learned rule
POST /abcd/def/gh HTTP/1.1 Content-type: text/x-gwt-rpc Host: 10.217.222.75 Content-length: 157 5|0|8|http://localhost:8080/acdtest/|16878339F02Baf83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String%3b|java.lang.Integer|onblur| The learn data will be as follows: > sh learningdata pr1 crossSiteScripting Profile: pr1 SecurityCheck: crossSiteScripting 1) Url: http://localhost:8080/acdtest/ >> From GWT Payload. Field: 10 Hits: 1 Done
Example of a GWT relaxation rule
bind appfw profile pr1 -crossSiteScripting 1 abcd -isregex NOTREGEX
Log Messages: The application firewall generates log messages for the security check violations that are detected in the GWT requests. A log message generated by a malformed GWT request contains the string “GWT” for easy identification.
Example of a Log message for malformed GWT request
Dec 5 21:48:02 <local0.notice> 10.217.31.247 12/05/2014:21:48:02 GMT ns 0-PPE-0 : APPFW Message 696 0 : "GWT RPC request with malformed payload. <blocked>”
Difference in processing of GWT vs non-GWT requests
The same payload can trigger different application firewall security check violations for different Content-types. Consider the following example:
A request sent with this content type results in a SQL violation if the SQL Injection Type is configured to use any of the four available options: SQLSplCharANDKeyword, SQLSplCharORKeyword, SQLKeyword, or SQLSplChar. The application firewall considers '&' to be the field separator and '=' to be the name-value separator when processing the above payload. Since neither of these characters appears anywhere in the post body, the entire content is treated as a single field name. The field name in this request contains both an SQL special character (;) and an SQL Keyword (select). Therefore violations are caught for all four SQL Injection type options.
A request sent with this content type triggers an SQL violation only if the SQL injection type is set to one of the following three options:SQLSplCharORKeyword,SQLKeyword, or SQLSplChar. No violation is triggered if the SQL injection type is set to SQLSplCharANDKeyword, which is the default option. The application firewall considers the vertical bar ' | ' to be the field separator for the above payload in the GWT request. Therefore, the post body is divided into various form-field values, and form-field names are added (in accordance with the convention described earlier). Because of this splitting, the SQL special character and SQL keyword become parts of separate form fields.
Form field 8: java.lang.String%3b -> %3b is the (;) char
Form Field 10: select
As a result, when SQL Injection Type is set to SQLSplChar, field 8 indicates the SQL violation. For SQLKeyword, field 10 indicates the violation. Either of these two fields can indicate a violation if the SQL Inject type is configured with the SQLSplCharORKeyword option, which looks for the presence of either a keyword or a special character. No violation is caught for the default SQLSplCharANDKeyword option, because there is no single field that has a value that contains both SQLSplChar and SQLKeyword together.