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 <colin@colinalworth.com> 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 an.s...@gmail.com 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
> an.s...@gmail.com 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
> google-web-toolkit+unsubscribe@googlegroups.com
> <mailto:google-web-toolkit+unsubscribe@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>.
>
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7c834ce8-0dc8-3e53-72ad-0c6c12a596ad%40gmail.com.
No comments:
Post a Comment