Is GWT RPC secure in 2.11?

[cbruno...@gmail.com]

Love GWT RPC as its makes calling code on the server seamless. I was reading however that it might not be secure (so issue with arbitrary code execution). Im not a security expert Can someone give me the status of RPC and the security issue with sending annotated POJOs?  

[Colin Alworth]

There was a security issue that we were made aware of up until 2.10:

https://bishopfox.com/blog/gwt-unpatched-unauthenticated-java-deserialization-vulnerability

https://github.com/gwtproject/gwt/issues/9709

https://github.com/gwtproject/gwt/pull/9879

This was fixed in the 2.10.1 and 2.11.0 releases - 2.11.0 was about to go out so we tacked on another change for it, and 2.10.1's only change was this same fix, backported.

There are other future changes to restore the "enhanced classes" feature, but I haven't seen any serious interest in it, so we might not end up restoring it, but removing it entirely?

https://github.com/gwtproject/gwt/issues/9880

https://github.com/gwtproject/gwt/issues/9881

[cbruno...@gmail.com]

Thanks for the response. The main need is to be able to annotate POJOs in the shared folder with JPA annotations and still be usable on the client. 

[Colin Alworth]

If you haven't disabled the check added in the linked PR, you are secure. Any insecure servlet will fail to start up, with: "ERROR: Service deserializes enhanced JPA/JDO classes, which is unsafe". An exception will be thrown, and you either must circumvent the check by disabling it, or must change the service/bean to prevent the condition from happening.

If you have disabled that check, you will see a warning in your server logs after the first time the service is called: "WARNING: Service deserializes enhanced JPA/JDO classes, which is unsafe...". This is unsafe.

Regardless of whether or not you disable the check, if a serializable bean/DTO/POJO has JPA/JDO annotations on it, there will be a GWT compiler warning. If that type is never actually readable from an RPC RemoteService that is used, neither of the above error/warning will occur, and your application is safe.

If you did disable that check, you need some way to either guarantee that the user cannot or will not send dangerous payloads, issues 9880 and 9881 outline approaches we could consider as a toolkit to resolve this. Beyond the contents of the linked issues, there isn't much I can suggest in the space of an email without much more information about your codebase and use cases.