What we’ve done is saved a reference to a real pong (which we cannot easily clone), and made the data attribute writeable. It’s okay to admit that forging a trusted message is exciting. To save you yet more time, one cannot just forge a trusted EventMessage object (a real message received by WebSocket) and modify it some engineering needs to be done to tamper with a read-only event message to return a valid pong, such as making the data attribute writeable. It’s trivial to spoof a pong from the DevTools console, but we shouldn’t be satisfied sending a simple JSON string as a pong, though let’s really forge a trusted EventMessage with all the trappings and attributes of a real message received on the wire. Instead, let’s intercept the ping, massage it into a tickle, and “receive” a well-crafted pong into the WebSocket layer so the client-side JavaScript is satisfied.
What happened is no more pings were sent after one ping was framejacked and then Slack just stopped working a short while later. Should we prevent the socket from being closed? Here is an experiment I ran by editing the cache of a Slack JavaScript file. Let’s not interfere with the Slack JavaScript or try to hack private variables.
Question: How can we safely framejack a ping then?
0 kommentar(er)
