ADC

Web App Firewall support for Google web toolkit

September 27, 2025

Contributed by:

C S S

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 Web App 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

https://www.quora.com/What-web-applications-use-Google-Web-Toolkit-%28GWT%29

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. Configure the “InspectQueryContentTypes” parameter of the App Firewall profile to “OTHER” to examine the request query portion for conent-type “text/x-gwt-rpc”.

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|
<!--NeedCopy-->

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:

The members of the above pipe delimited string table contain the user-provided inputs. These inputs are parsed for the Web App Firewall checks and are identified as follows:

1st : http://localhost:8080/test/

This is the Request URL.
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

<container>.<sub-cntnr>.name/<integer><identifier>

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.

Web App Firewall protection for GWT applications

The Web App Firewall understands and interprets GWT RPC requests, inspects the payload for security check violations, and takes specified actions.

The Web 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 Web 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 Web App Firewall.

Learning and relaxation rules: Learning and deployment of relaxation rules are supported for GWT requests. Web App 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 Web 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.

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 Web App 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 Web 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
 <!--NeedCopy-->

Example of a GWT relaxation rule

bind appfw profile pr1 -crossSiteScripting 1 abcd -isregex NOTREGEX

Log Messages: The Web 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 Web App 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 Web 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.

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

Tips:

No special Web 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 Web 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.

The official version of this product documentation is in English. Any non-English version is solely provided for your convenience and may include machine-translated content. For more information, please refer to the Machine Translation Disclaimer on Cloud Software Group home.

Was this helpful

NetScaler Secure Deployment Guide

Web App Firewall support for Google web toolkit

September 27, 2025

Contributed by:

C S S

September 27, 2025

Contributed by:

C S S

Web App Firewall support for Google web toolkit

What is GWT

How a GWT request works

Web App Firewall protection for GWT applications

In this article