App Firewall support for Google web toolkit
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 App App Firewall without a need for any specific configuration to enable the GWT support.
What is GWT
For popular websites that use GWT, see
How a GWT request works
The GWT RPC request is pipe delimited and has variable number of arguments. It is carried as a payload of HTTP POST and has the following values:
- Content-type = text/x-gwt-rpc. Charset can be any value.
- Method = POST.
Both GET and POST HTTP requests are considered valid GWT requests if content-type is “text/x-gwt-rpc”. Query strings are now supported as part of GWT requests.
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:
|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|
The members of the above pipe delimited string table contain the user-provided inputs. These inputs are parsed for the App Firewall checks and are identified as follows:
This is the Request URL.
2nd : 16878339F02B83818D264AE430C20468
Unique HEX identifier. A request is considered malformed if this string has non-hex characters.
rd : com.test.client.TestService
Service Class name
4th : testMethod
Service method name
5th onwards: java.lang.String java.lang.Integer myInput1 java.lang.Integer/3438268394
Data-types and data. Non-primitive data-types are specified as
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.
App Firewall protection for GWT applications
The App Firewall understands and interprets GWT RPC requests, inspects the payload for security check violations, and takes specified actions.
The App 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 App 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 App Firewall.
Learning and relaxation rules: Learning and deployment of relaxation rules are supported for GWT requests. App Firewall rules are in the form of
<fieldName> mapping. The GWT request format does not have the field names and thus requires special handling. The App Firewall inserts dummy field names in the learned rules that can be deployed as relaxation rules. The -isRegex flag works as it does for non-GWT rules.
Multiple services responding to an RPC can be configured on the same web server. The HTTP request has the URL of the web server, not of the actual service handling the RPC. Therefore, relaxation is not applied on the basis of the HTTP request URL, because that would relax all the services on that URL for the target field. For GWT requests, the App Firewall uses the URL of the actual service found in the GWT payload, in the fourth field in the string table.
Since the GWT request body contains only field values, the App Firewall inserts dummy field names such as 1, 2, and so on when recommending learned rules.
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 App 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 App 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 App 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 App 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.
- No special App Firewall configuration is needed to enable GWT support.
- The Content-type must be text/x-gwt-rpc.
- Learning and deploying of the relaxation rules for all the pertinent App Firewall security checks applied to GWT payload works the same as it does for the other supported content-types.
- Only POST requests are considered valid for GWT. All other request methods are blocked if the content-type is text/x-gwt-rpc.
- GWT requests are subject to the configured POST body limit of the profile.
- The sessionless setting for the security checks is not applicable and will be ignored.
- CEF log format is supported for the GWT log messages.