GWT RPC call recognized as a Java Method Injection by Fortiweb

127 views
Skip to first unread message

Giacomo Petronio

unread,
Jul 21, 2023, 5:38:59 AM7/21/23
to GWT Users
We have one deployment of a GWT app where there is a Fortiweb firewall that blocks every GWT RPC call because it recognizes every call as a Java Method Injection attack. This seems to be caused by the presence of the pattern "java.lang." in the messages from the client to the server like the following:

My idea is to convince the firewall administrator that these are false-positives as these calls are part of the GWT RPC mechanism that does not allow arbitrary java code execution on the server side.

Is my reasoning correct or am I not worried enough?

Thomas Broyer

unread,
Jul 21, 2023, 6:34:03 AM7/21/23
to GWT Users
Your reasoning is correct. But you can also obfuscate type names to prevent triggering the WAF: https://github.com/gwtproject/gwt/blob/main/user/src/com/google/gwt/user/RemoteServiceObfuscateTypeNames.gwt.xml 
(disclaimer: I haven't used RPC for more than 10 years)

Ralph Fiergolla

unread,
Jul 21, 2023, 10:43:49 AM7/21/23
to google-we...@googlegroups.com
I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/40bf5948-5d59-4d47-8686-7b1db98e80fdn%40googlegroups.com.

Paul Robinson

unread,
Jul 21, 2023, 3:54:59 PM7/21/23
to google-we...@googlegroups.com
Having readable network messages is very useful for debugging.

It's also easy to include more data in a GWT RPC messages than you really need unless you're careful with it.

Regards,
Paul

Jens

unread,
Jul 24, 2023, 12:23:52 PM7/24/23
to GWT Users
I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

Depends on your situation of course. If you want to use your existing backend with other clients written in other languages then GWT-RPC is a bad fit. While the wire format of GWT-RPC is documented, you still need to write the client code to generate it. Also GWT-RPC supports inheritance which other languages you want to use might not support. Other JS based RPC solutions as well as general purpose solutions like gRPC typically do not support inheritance.

GWT-RPC will already be annoying if you decide to have some portions of your app being written in a different framework since it is easier to find developers for that framework, e.g. angular, svelte, react, whatever. You would then need to define a JS api that calls into GWT code so these frameworks can talk to your GWT-RPC backend (or you need to provide new endpoints in your backend that do not talk GWT-RPC).

-- J.

Ralph Fiergolla

unread,
Jul 24, 2023, 1:50:38 PM7/24/23
to google-we...@googlegroups.com
That is, as long as I stay within GWT there is no need to change (and loose type checking and convenience). I will happily stay with GWT RPC then!

R

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

RobW

unread,
Jul 25, 2023, 9:23:53 AM7/25/23
to GWT Users
We got to a similar point. Looked in depth at moving the GWT front end to a REST API - but found two big drawbacks: 
  1. none of the frameworks we could find had async callback handling similar to GWT-RPC, with common interface classes client server side AND support JAX-RS subresources. RestyGWT got close apart from those last two points - there is a model with common client/server interfaces, but it doesn't support subresources. We found at least 1 other GWT REST toolkit that had exactly the same issue  - so it's clearly not a trivial one to solve.
  2. somewhat more serious than the first issue was that none of the GWT REST API frameworks looked to be that actively maintained, at least tracking their GitHub commits anyhow
So ultimately, although REST API an attractive route, GWT-RPC remains more practical for us in the near term.

Note - one we didn't explore in depth but may come back too was Domino Kit, which has a REST API component. That did look more actively maintained and perhaps is a way forward.

Michael Conrad

unread,
Jul 25, 2023, 10:43:06 AM7/25/23
to GWT Users
Did y'all test DominoKit? It is actively maintained and has a REST module. I'm curious if you did test it what shortcomings you may have run into.

RobW

unread,
Jul 26, 2023, 9:25:32 AM7/26/23
to GWT Users
As noted in the post - we didn't get around to trying Domino REST. By the time we discovered it, we'd already made the decision to stick with GWT-RPC and move on to other work. It's possible we'd revisit that, but we'd probably want to see some worked examples of how to transition from GWT-RPC to Domino REST. We already burnt quite a few cycles digging into the depths of alternates only to find they came up short. So it's hard to justify going back there to do more of that at this stage when GWT-RPC still works.

Vassilis Virvilis

unread,
Jul 26, 2023, 1:27:36 PM7/26/23
to google-we...@googlegroups.com
Super sourcing is a hackish but very powerful tool.
I have used it to override some gwt widgets in order to expose or change some private methods.

Is this feature so difficult to be implemented? I mean at that point J2CL looked like a cool upgrade when Google was standing behind GWT. But since it took forever to be released as part of GWT one may wonder if it is really needed at this point.

Vassilis Virvilis

unread,
Jul 26, 2023, 2:05:32 PM7/26/23
to google-we...@googlegroups.com
Wrong thread. Sorry. Please ignore.
Reply all
Reply to author
Forward
0 new messages