On 30 January 2014 14:22, Koehne Kai <[email protected]> wrote: > > >> -----Original Message----- >> From: [email protected] >> [...] >> Again, only 3rd party untrusted content matters here and for that you need a >> sandbox. > > I'm not entirely sure '3rd party untrusted content' in the Qt process is > needed for these sort of attacks. > > That's how I understood it so far: > 1. the attack vector is web proxy poisoning. That is , all it takes is an > attacker that > a) can access a remote under his control through the same proxy as the target > (or gets some user behin the proxy to access the remote) > b) knows how the websocket request will look like > c) Manages to poison the proxy to cache a poisonous answer for the request > > The hashing stuff etc tries to prevent b), but strong entropy is required so > that the attacker can't just 'guess' future requests e.g. from monitoring > previous requests. > > Correct me if I'm wrong, but that scheme will work independent of whether the > user / app itself runs untrusted content etc. >
Yes it would... except that if the attacker can execute arbitrary code then he doesn't have to use this API - he can just do the attack. The masking comes in useful when the attacker is sandboxed so can only perform the attack using the subset of facilities exposed to him - in this case the websockets api. Cheers Rich. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
