How does the data format for Google Web Toolkits (GWT) RPC calls look and how are IsSerializable objects transmitted. I know that Java Serializable transmits some kind of binary format, but is this the case with GWT too? (Since I don't expect it to be compatible with JavaScript, or at least require some additional parsing).
1 Answers
EDIT: Brian Slesinsky just documented the protocol (by reverse-engineering the code): https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit
First, GWT-RPC protocol is asymmetric so that it's always optimized for the client-side: fast to deserialize something coming from the server, and fast to serialize something to send to it.
It's obviously not binary, as you suspected, but text-based. client-to-server protocol is pipe-delimited while server-to-client is based on JSON (with a //OK
or //EX
prefix to tell whether the request succeeded or failed). Both use the common knowledge of the serializable classes to serialize/deserialize; for instance, both sides know that class X has two fields, an integer and a String, serialized in that order, so they both write/read an integer, and then a String, with no need to specify in the encoded format which field it's about.
GWT-RPC protocol is versionned (it changes regularly as new GWT versions are released), and uses hashes of the class and serializable fields' names to ensure the client and server both use the same versions of the classes (which means you have to recompile and redeploy your client code each time you change a serializable class).
The best documentation is the code, but you'll find an overview of the request format in these slides: https://www.owasp.org/images/7/77/Attacking_Google_Web_Toolkit.ppt
RequestFactory, contrary to GWT-RPC, uses a symmetric JSON-based protocol (based on AutoBean's JSON serialization) where client and server can communicate even when not compiled from the same code (well, depending on the changes you made between versions, of course), because they pass around class and property names.

- 64,353
- 7
- 91
- 164
-
1great answer, btw do you know of any none java implementaions for GWT_RPCs? – Stefan May 26 '11 at 12:26
-
Google tells me about http://code.google.com/p/gwtphp/ and http://code.google.com/p/python-gwt-rpc/ but they look abandonned (and RequestFactory is the way to go, but I'm not aware of any non-Java implementation) – Thomas Broyer May 26 '11 at 19:03
-
thanks again. According to this, when I want to talk with none java server RPC isn't the way to go, I should some ohter custom JSON or XML protocol. – Stefan May 27 '11 at 06:51
-
Then use `AutoBean`s for JSON serialization. – Thomas Broyer May 27 '11 at 08:02
-
I've written something using this question, the doc and sparse bits I could find on the net (I needed to scrape one site). Can be used as a starting point maybe if you'll need a simple thing to decode it. It's dirty, but maybe will save some time for an adventurous soul. https://github.com/aikipooh/python_gwt – aikipooh Mar 13 '17 at 10:11
-
In my project, we are working on fixing SQL injection risks associated with inputs received via our GWT App. My query is - is there a need to sanitize the request content before passing it to further tiers - are there any risks known to be with GWT Message format? For example - XMLs are known to have [XXE](https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing) risks. For example: if there was no SQL queries executed for a given GWT RPC, what kind of risks that GWT pipe separate format has which can be exploited by a hacker? – Wand Maker Aug 16 '17 at 12:07
-
There's no known vulnerability in the GWT-RPC protocol. There's a possible Java deserialization vulnerability in some very specific circumstances, I don't have the details right now, but it cannot be triggered if the serialization policy doesn't allow it. IIRC, it could be the case if you use DataNucleus and transfer processed classes. – Thomas Broyer Aug 18 '17 at 21:59