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!
On 20.10.23 20:12, Colin Alworth <[email protected]> wrote:
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).
On Friday, October 20, 2023 at 12:59:15 PM UTC-5 Thomas Broyer wrote:
You could have a look at
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
use "binary" nowadays.
On Friday, October 20, 2023 at 3:10:17 PM UTC+2 [email protected] wrote:
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é
Colin Alworth schrieb am Freitag, 20. Oktober 2023 um 14:55:53
UTC+2:
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 <https://github.com/vertispan/gwt-rpc>, 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
<https://developer.mozilla.org/en-US/docs/Web/API/WebSocket>
for more information on what the browser's own WebSocket
type offers.
On Friday, October 20, 2023 at 7:31:03 AM UTC-5
[email protected] wrote:
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é
--
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
[email protected]
<mailto:[email protected]>.
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>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit/7c834ce8-0dc8-3e53-72ad-0c6c12a596ad%40gmail.com.
