Maciej Stachowiak wrote: > I believe the only component that absolute has to check for violations > of the sentinel framing to maintain security is the browser - it needs > to prevent script code running in the browser from doing shady things > to an existing connection, so it can't let scripts inject a sentinel. Every component which forwards data and needs to track the frame boundaries, including those which just use it to control buffering, need to scan every byte and are vulnerable to injection attacks. A simple forwarding component may track frame boundaries to buffer up a whole message before forwarding it. A frame injection attack can fool such a component to cause an unbounded delay in delivering that or later messages, breaking application expectations. Other things which have been discussed such as orderly close, keepalives and so on can be very broken by a frame injection attack on an earlier frame. Web pages with multiple Javascript components sharing a connection through a simple framework - which is the primary target for WebSocket I believe - may be tricked into things like retrying a state changing request sent to the server when it is not safe to do so, causing the state change twice, despite the application protocol being carefully coded to make that "impossible". Because of a frame injection attack breaking protocol assumptions. If a receiver supported the gzipped binary frame which was mentioned, a sentinel frame injection attack could inject a gzipped frame which may decode in all sorts of ways... denial of service at least. If anything, the *sender* has to be especially careful to check for violations, otherwise the whole delivery chain may go wrong. -- Jamie
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.