Re: IQ Handling vulnerabilities

On Sun, Feb 9, 2014 at 9:13 AM, Thijs Alkemade <[email protected]> wrote:
>
>> I'm not saying that we shouldn't generally recommend unpredictable ids - it seems relatively simple and causes little harm - but cryptographically secure ones seems overkill, and I'm always nervous of imposing unneeded drains on the entropy store of a system.
>>
>> Also, I've mentioned this elsewhere, but I'll mention it here too: much of the XMPP community seems focussed on clients exhibiting this class of bug, and attacks against those clients. I strongly suspect that not all servers are immune to this, and the attacks on servers are likely to be just as fascinating.
>
> I'm trying to think of a situation where the server sends a iq 'get' to the
> client, but I don't really know any. A lot of iq 'set's, where the server
> informs the client of something (and probably doesn't really care whether that
> results in an 'error' or 'result'), but nothing where the server wants to know
> something from the client. Could you give an example?
>

disco#info requests for PEP, though in this case Prosody happily uses
a single constant id for all requests, only using the sender's JID and
subscription status.
MUC is another when it proxies IQ requests (vCards, private IQs), and
for vCards Prosody encodes a bunch of information in the id for
verification.

A quick search through prosody-modules found implementations of
XEP-0309: Service Directories and XEP-268: Incidents Handling
listening for IQ results.

--
Waqas Hussain