GWT: Deserialize objects sent/received via websocket

[An Schall]

Hi,

I am very new to GWT and have questions about the basic principles of how GWT via websockets work.

I would like to analyze the authentication function of a given GWT web application. When authenticating with my credentials, I could identify that my credentials are sent via websocket in form of a binary blob. This most certainly is a serialized GWT object. The authentication seems to follow a protocol that involves 3-4 messages exchanged with the server-side.

Hence, I strive to understand how the client-side transforms my textual credentials (username / password) into this binary blob. Subsequently, I would like to understand how I can deserialize messages coming from the server in order to get a better idea of the messages exchanged and hence the protocol.

Thanks,

André

[Colin Alworth]

While GWT offers websocket support, the only support is "now you can send messages on a websocket" - no serialization is offered, beyond what the browser itself provides (allowing sending a utf8 string, arraybuffers, blobs, typedarrays, or arrayviews). How are you verifying messages sent/received? If you are observing some 3-4 websocket frame handshake messages on the websocket, that is probably some other GWT library in use - which WebSocket class are you using?

I maintain (and use in production) an rpc-over-websocket implementation, but it does not explicitly support authentication. Instead usually the first message authenticates with the server, or HTTP headers are used to authenticate (potentially using existing cookies) before the websocket is even initiated. So at least we can probably rule out that implementation.

See https://developer.mozilla.org/en-US/docs/Web/API/WebSocket for more information on what the browser's own WebSocket type offers.

[An Schall]

Dear Colin,

thanks for the quick response. I did observe the authentication approach via BurpSuite that allows me to investigate each HTTP / websocket request / response. From this perspective, I can see that upon submitting my credentials to the webapp, there is only one HTTP POST request from client-side that only includes the username. After this initial POST request, all the communication goes over websocket with binary blobs being exchanged. Hence, it is not easy for me to identify which GWT library class is in use.

Is there any way how to get this information, (i.e. I could provide the URL of the endpoint I am talking to).

Best,

André

[Thomas Broyer]

You could have a look at https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit to see what GWT-RPC exchanges look like and see if they match what you're seeing. But they're not "binary".

I didn't follow what gRPC (Google's RPC format: https://grpc.io/) looks like on the web, but it's possible they use "binary" nowadays.

[Colin Alworth]

Seeing traffic wouldn't hurt, but it would be easiest to discover by looking at code - finding "WebSocket" in the codebase, then seeing what the import is. Alternatively, the compiled JS will probably have some hints, depending on how it was built.

As to the authentication approach you clarified - if the client sends a POST before the websocket is created that performs the authentication, it is quite likely that the server responds by setting a cookie, and that all subsequent HTTP requests (including the websocket) are authenticated with that cookie. It is also possible that the websocket's binary blobs contain the credentials again, or more likely, the session ID.

gRPC is indeed typically binary protobuf data... but gRPC can't be used in a browser in 2023. gRPC-web is a thing... which can't stream binary data, and can't stream data to the server (using the tooling provided by the gRPC project itself). There are alternative gRPC-web clients that can support streaming binary data _from_ the server, but in 2023 the fetch() API is still server streaming only, even with h2. There are even really-alternative gRPC clients for the browser that rely on websockets as well, but if you get in a situation where you want more than a small handful of concurrent streams the browser just hangs on new calls, so I can't recommend that, unless you use the websocket to replace the h2 transport rather than using it per-stream (but now you've got more work to make sure you clean up streams promptly, and they aren't a lot of fun to debug).

[an.s...@gmail.com]

Hi everyone,

thanks for all the thoughts about the topic. After further investigation of the protocol, it seems like there is no pbject serialization involved. Instead, the application creates a websocket and establishes a AES-CBC encrypted channel. Hence, the binary blobs that I was seeing are encrypted messages. If somebody is interested, the website is https://metatraderweb.app/trade

Thanks again!

> https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit <https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit> to see what GWT-RPC exchanges look like and see if they match what you're seeing. But they're not "binary".

>
> I didn't follow what gRPC (Google's RPC format: https://grpc.io/

> <https://grpc.io/>) looks like on the web, but it's possible they

> implementation <https://github.com/vertispan/gwt-rpc>, but

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/q0QxVCumk6I/unsubscribe <https://groups.google.com/d/topic/google-web-toolkit/q0QxVCumk6I/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> google-web-tool...@googlegroups.com
> <mailto:google-web-tool...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/693c5f07-aac5-4580-aa8f-35684326cf83n%40googlegroups.com <https://groups.google.com/d/msgid/google-web-toolkit/693c5f07-aac5-4580-aa8f-35684326cf83n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>

[Thomas Broyer]

On Sunday, October 22, 2023 at 3:25:18 PM UTC+2 an.s...@gmail.com wrote:

Hi everyone,

thanks for all the thoughts about the topic. After further investigation of the protocol, it seems like there is no pbject serialization involved. Instead, the application creates a websocket and establishes a AES-CBC encrypted channel. Hence, the binary blobs that I was seeing are encrypted messages. If somebody is interested, the website is https://metatraderweb.app/trade

I'm curious what made you think this is related to GWT: I don't see anything pointing to the use of GWT on that app.

The "gwt" mentions in the code (and server names) look more like an acronym of "G-something Web Trader" to me.