Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

[Paul Robinson]

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

On Fri, 21 Jul 2023, 15:43 Ralph Fiergolla, 
wrote:

> 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?
>
> Thomas Broyer  schrieb am Fr. 21. Juli 2023 um 12:34:
>
>>
>>
>> On Friday, July 21, 2023 at 11:38:59 AM UTC+2 petr...@o3enterprise.com
>> wrote:
>>
>> 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:
>>
>> 7|0|7|https://host/app/app_gui/|BD9331DABCA5012FC56F3600DF03415F|com.app.gui.client.Bridge|getClientConfiguration|java.lang.St
>> ring/2004016611|john|ADMINISTRATOR|1|2|3|4|2|5|5|6|7|
>> 
>>
>> 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?
>>
>>
>> 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)
>>
>> --
>> 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-toolkit+unsubscr...@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
>> 
>> .
>>
> --
> 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-toolkit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/CACwwWxPGRqV2pBTq4iPr4mmbE%2Bb38sxzAZuN%3D__z%2BemUACS5%3Dw%40mail.gmail.com
> 
> .
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/CAGHNWNLxJj2xtR6HGZG6R9m20LPpwwFaO%2B1BEGrvouvQK_vbcQ%40mail.gmail.com.

Re: Partial super source? Possible?

[Colin Alworth]

I don't use String.format() a lot, even in the normal JVM, but based on the 
Javadoc it looks like we could add the format method, and delegate to a 
java.util.Formatter, but then leave that unimplemented by default. Then, 
downstream applications could more easily add that, without having to worry 
about keeping the rest of String.java up to date? 

Note also when trying to do anything beyond simple %s replacement, the 
java.util.Locale type exists in GWT emulation, but offers no instance 
methods outside of toString.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/String.html#format(java.lang.String,java.lang.Object...)
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Formatter.html
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Locale.html


On Friday, July 21, 2023 at 4:38:24 AM UTC-5 Thomas Broyer wrote:

> GWT standard emulation is "just" super-source itself. You cannot "augment" 
> it, but you can "shadow" it by providing your own super-source version of 
> java.lang.String (copy from GWT and patch; and make sure it appears before 
> GWT's emulation in the source path – i.e. IIRC make sure the  
> comes before any  that would bring com.google.gwt.emul.Emulation). 
> This means you'll have to update your version whenever GWT updates its own.
> But only ever do this for an application, never for a library!
>
> On Thursday, July 20, 2023 at 1:46:15 PM UTC+2 Bruno Salmon wrote:
>
>> hi,
>>
>> If GWT emulates a Java class but not all methods, is it possible to 
>> provide a complement as a super source?
>>
>> For example, can I provide a super source for String.format() while 
>> keeping other String methods emulated by GWT?
>>
>> Thanks
>>
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/86163e40-07e8-47de-9ce9-4abfd81df242n%40googlegroups.com.

Re: GWT compilation issue with jdk 17

[Colin Alworth]

There is community work underway 
 to update GWT-RPC itself to 
use jakarta.servlet packages, and the same idea could be applied to 
gwtplatform. Unfortunately, the gwtplatform.com domain is still owned, so 
any fork could not take over the groupid, but would need to pick a new one, 
which might cause some irritation when upgrading. I do see that the domain 
is scheduled to expire next year, but that probably isn't long enough to 
wait. It might be possible to contact the former owners to get permission 
for this work to be published as well. If you take that route, I'd be 
interested in being involved.

I've used the eclipse transformer before, and personally found it to be 
more trouble that it is worth. 


On Friday, July 21, 2023 at 8:03:56 AM UTC-5 NIKITAH wrote:

> Thank you Thomas for your guidance .
>
> On Friday, July 21, 2023 at 6:25:36 PM UTC+5:30 Thomas Broyer wrote:
>
>> On Friday, July 21, 2023 at 12:51:32 PM UTC+2 NIKITAH wrote:
>>
>> Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest 
>> which version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 
>> 9.0 ?
>>
>>
>> None!
>>
>> Repeating myself here: 
>>
>>
>>- GWTP is long dead; at least one year before the Javax/Jakarta mess 
>> was 
>>even announced (except for one never-released commit in Sept. 2018)
>>
>> Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or 
>> migrate away from legacy/abandoned libs and frameworks that lock them to 
>> Java EE.
>>
>>
>> Now paraphrasing myself, you have to either:
>>
>>- stay on Jakarta EE 8 (or earlier Java EE)
>>- rewrite the whole thing to remove GWTP
>>- transform GWTP to Jakarta EE 9+ with the help of tools like Eclipse 
>>Transformer 
>>
>>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/c27903b8-a23b-4d9b-bc75-465e53b1d1ean%40googlegroups.com.

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

[Ralph Fiergolla]

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?

Thomas Broyer  schrieb am Fr. 21. Juli 2023 um 12:34:

>
>
> On Friday, July 21, 2023 at 11:38:59 AM UTC+2 petr...@o3enterprise.com
> wrote:
>
> 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:
>
> 7|0|7|https://host/app/app_gui/|BD9331DABCA5012FC56F3600DF03415F|com.app.gui.client.Bridge|getClientConfiguration|java.lang.St
> ring/2004016611|john|ADMINISTRATOR|1|2|3|4|2|5|5|6|7|
> 
>
> 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?
>
>
> 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)
>
> --
> 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-toolkit+unsubscr...@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
> 
> .
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/CACwwWxPGRqV2pBTq4iPr4mmbE%2Bb38sxzAZuN%3D__z%2BemUACS5%3Dw%40mail.gmail.com.

Re: GWT compilation issue with jdk 17

[NIKITAH]

Thank you Thomas for your guidance .

On Friday, July 21, 2023 at 6:25:36 PM UTC+5:30 Thomas Broyer wrote:

> On Friday, July 21, 2023 at 12:51:32 PM UTC+2 NIKITAH wrote:
>
> Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest 
> which version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 
> 9.0 ?
>
>
> None!
>
> Repeating myself here: 
>
>
>- GWTP is long dead; at least one year before the Javax/Jakarta mess 
> was 
>even announced (except for one never-released commit in Sept. 2018)
>
> Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or 
> migrate away from legacy/abandoned libs and frameworks that lock them to 
> Java EE.
>
>
> Now paraphrasing myself, you have to either:
>
>- stay on Jakarta EE 8 (or earlier Java EE)
>- rewrite the whole thing to remove GWTP
>- transform GWTP to Jakarta EE 9+ with the help of tools like Eclipse 
>Transformer 
>
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/53d30f6a-4d0b-4411-9e78-4eb987d1f0e7n%40googlegroups.com.

Re: GWT compilation issue with jdk 17

[Thomas Broyer]

On Friday, July 21, 2023 at 12:51:32 PM UTC+2 NIKITAH wrote:

Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest which 
version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 9.0 ?


None!

Repeating myself here: 


   - GWTP is long dead; at least one year before the Javax/Jakarta mess 
    was even 
   announced (except for one never-released commit in Sept. 2018)

Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or 
migrate away from legacy/abandoned libs and frameworks that lock them to 
Java EE.


Now paraphrasing myself, you have to either:

   - stay on Jakarta EE 8 (or earlier Java EE)
   - rewrite the whole thing to remove GWTP
   - transform GWTP to Jakarta EE 9+ with the help of tools like Eclipse 
   Transformer 

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/bb903f74-9480-49f9-b600-6f7dec5648d0n%40googlegroups.com.

Re: GWT compilation issue with jdk 17

[NIKITAH]

Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest which 
version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 9.0 ?

On Friday, July 21, 2023 at 3:58:59 PM UTC+5:30 Thomas Broyer wrote:

> Two things:
>
>
>- using JDK 17 doesn't mean you have to use Jakarta EE 9+, Java EE 8 / 
>Jakarta EE 8 should still work just fine. You may have also changed your 
>server to a Jakarta EE 9+ version, but that's (almost) independent from 
>using JDK 17
>- GWTP is long dead; at least one year before the Javax/Jakarta mess 
> was 
>even announced (except for one never-released commit in Sept. 2018)
>
> Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or 
> migrate away from legacy/abandoned libs and frameworks that lock them to 
> Java EE.
>
> On Friday, July 21, 2023 at 11:52:55 AM UTC+2 NIKITAH wrote:
>
>>
>> Just FYI , I've already tried with  gwtp-dispatch-rest-1.6.jar and facing 
>> the same issue  " The import javax.ws.rs.core.HttpHeaders cannot be 
>> resolved" .
>> As , we are aware in jdk17 we are using Jakarta API means  HttPheaders is 
>> now moved to jakarta.ws.rs.core.HttpHeaders . 
>> So , wanted to know if there is any gwtp-dispatch-rest jar with JDK 17.
>>
>> On Thursday, July 20, 2023 at 3:11:38 PM UTC+5:30 NIKITAH wrote:
>>
>>> Hi , 
>>>
>>> I am trying to compile GWT with JDK17.
>>> As per 
>>> https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0 , I 
>>> came to know that GWT2.10.0 is compatible with JDK17 and hence I updated 
>>> the same in my project .
>>>
>>> Now, facing issue with gwtp-dispatch-rest-1.4.jar like : 
>>> [ERROR] Line 24: The import javax.ws.rs.core.HttpHeaders cannot be 
>>> resolved
>>> [ERROR] Line 95: HttpHeaders cannot be resolved to a variable
>>>
>>> Can someone please help and let me know which version of 
>>> gwtp-dispatch-rest-*.jar is compatible with JDK 17 .
>>>
>>> Thanks in advance .
>>>
>>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/52e3013d-813a-4156-ac8a-82bde21af7b9n%40googlegroups.com.

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

[Thomas Broyer]

On Friday, July 21, 2023 at 11:38:59 AM UTC+2 petr...@o3enterprise.com 
wrote:

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:

7|0|7|https://host/app/app_gui/|BD9331DABCA5012FC56F3600DF03415F|com.app.gui.client.Bridge|getClientConfiguration|java.lang.St
 
ring/2004016611|john|ADMINISTRATOR|1|2|3|4|2|5|5|6|7| 


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?


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)

-- 
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-toolkit+unsubscr...@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.

Re: GWT compilation issue with jdk 17

[Thomas Broyer]

Two things:


   - using JDK 17 doesn't mean you have to use Jakarta EE 9+, Java EE 8 / 
   Jakarta EE 8 should still work just fine. You may have also changed your 
   server to a Jakarta EE 9+ version, but that's (almost) independent from 
   using JDK 17
   - GWTP is long dead; at least one year before the Javax/Jakarta mess 
    was even 
   announced (except for one never-released commit in Sept. 2018)

Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or 
migrate away from legacy/abandoned libs and frameworks that lock them to 
Java EE.

On Friday, July 21, 2023 at 11:52:55 AM UTC+2 NIKITAH wrote:

>
> Just FYI , I've already tried with  gwtp-dispatch-rest-1.6.jar and facing 
> the same issue  " The import javax.ws.rs.core.HttpHeaders cannot be 
> resolved" .
> As , we are aware in jdk17 we are using Jakarta API means  HttPheaders is 
> now moved to jakarta.ws.rs.core.HttpHeaders . 
> So , wanted to know if there is any gwtp-dispatch-rest jar with JDK 17.
>
> On Thursday, July 20, 2023 at 3:11:38 PM UTC+5:30 NIKITAH wrote:
>
>> Hi , 
>>
>> I am trying to compile GWT with JDK17.
>> As per https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0 
>> , I came to know that GWT2.10.0 is compatible with JDK17 and hence I 
>> updated the same in my project .
>>
>> Now, facing issue with gwtp-dispatch-rest-1.4.jar like : 
>> [ERROR] Line 24: The import javax.ws.rs.core.HttpHeaders cannot be 
>> resolved
>> [ERROR] Line 95: HttpHeaders cannot be resolved to a variable
>>
>> Can someone please help and let me know which version of 
>> gwtp-dispatch-rest-*.jar is compatible with JDK 17 .
>>
>> Thanks in advance .
>>
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/fb2910fb-7cf9-4dc8-b9b9-f6c661f51e9cn%40googlegroups.com.

Re: GWT compilation issue with jdk 17

[NIKITAH]

Just FYI , I've already tried with  gwtp-dispatch-rest-1.6.jar and facing 
the same issue  " The import javax.ws.rs.core.HttpHeaders cannot be 
resolved" .
As , we are aware in jdk17 we are using Jakarta API means  HttPheaders is 
now moved to jakarta.ws.rs.core.HttpHeaders . 
So , wanted to know if there is any gwtp-dispatch-rest jar with JDK 17.

On Thursday, July 20, 2023 at 3:11:38 PM UTC+5:30 NIKITAH wrote:

> Hi , 
>
> I am trying to compile GWT with JDK17.
> As per https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0 
> , I came to know that GWT2.10.0 is compatible with JDK17 and hence I 
> updated the same in my project .
>
> Now, facing issue with gwtp-dispatch-rest-1.4.jar like : 
> [ERROR] Line 24: The import javax.ws.rs.core.HttpHeaders cannot be resolved
> [ERROR] Line 95: HttpHeaders cannot be resolved to a variable
>
> Can someone please help and let me know which version of 
> gwtp-dispatch-rest-*.jar is compatible with JDK 17 .
>
> Thanks in advance .
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/ef930587-59f1-4307-a56a-f4a668ff6c75n%40googlegroups.com.

GWT RPC call recognized as a Java Method Injection by Fortiweb

[Giacomo Petronio]

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:

7|0|7|https://host/app/app_gui/|BD9331DABCA5012FC56F3600DF03415F|com.app.gui.client.Bridge|getClientConfiguration|java.lang.St
 
ring/2004016611|john|ADMINISTRATOR|1|2|3|4|2|5|5|6|7|

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?

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/2e3678f0-8846-4a5c-a113-746383473e07n%40googlegroups.com.

Re: Partial super source? Possible?

[Thomas Broyer]

GWT standard emulation is "just" super-source itself. You cannot "augment" 
it, but you can "shadow" it by providing your own super-source version of 
java.lang.String (copy from GWT and patch; and make sure it appears before 
GWT's emulation in the source path – i.e. IIRC make sure the  
comes before any  that would bring com.google.gwt.emul.Emulation). 
This means you'll have to update your version whenever GWT updates its own.
But only ever do this for an application, never for a library!

On Thursday, July 20, 2023 at 1:46:15 PM UTC+2 Bruno Salmon wrote:

> hi,
>
> If GWT emulates a Java class but not all methods, is it possible to 
> provide a complement as a super source?
>
> For example, can I provide a super source for String.format() while 
> keeping other String methods emulated by GWT?
>
> Thanks
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/853444d3-8f18-483a-82f6-0bd0eaa55acbn%40googlegroups.com.