Product Documentation

Application Firewall Support for Google Web Toolkit

Mar 23, 2015

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.

What is GWT

The GWT is used for building and optimizing complex high-performance web applications by people who do not have expertise in XMLHttpRequest, and JavaScript. This open source, free development toolkit is used extensively for developing small and large scale applications and is quite frequently used for displaying browser based data such as search results for flights, hotels, and so on. The GWT provides a core set of Java APIs and widgets for writing optimized JavaScript scripts that can run on most browsers and mobile devices. The GWT RPC framework makes it easy for the client and server components of the web application to exchange Java objects over HTTP. GWT RPC services are not the same as web services based on SOAP or REST. They are simply a lightweight method for transferring data between the server and the GWT application on the client. GWT handles serialization of the Java objects exchanging the arguments in the method calls and the return value.

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:
  1. Content-type = text/x-gwt-rpc. Charset can be any value.
  2. Method = POST.

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|

The members of the above pipe delimited string table contain the user-provided inputs. These inputs are parsed for the application firewall checks and are identified as follows:
  • 1st : http://localhost:8080/test/

    This is the Request URL. It should not contain the query part, because the GET method is not allowed.

  • 2nd : 16878339F02B83818D264AE430C20468

    Unique HEX identifier. A request is considered malformed if this string has non-hex characters.

  • 3rd : 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


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.

Application firewall protection for GWT applications

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.

Learning and relaxation rules: Learning and deployment of relaxation rules are supported for GWT requests. Application firewall rules are in the form of <actionURL> <fieldName> mapping. The GWT request format does not have the field names and thus requires special handling. The application 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.
Action URL:
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 application firewall uses the URL of the actual service found in the GWT payload, in the fourth field in the string table.
Field name:
Since the GWT request body contains only field values, the application 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 
Content-length: 157 
  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 

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> 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:


Content-type: application/x-www-form-urlencoded

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.

Content-type: text/x-gwt-rpc

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.

  • No special application 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 application 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.