I've been looking into XMPP implementations and whether they verify the source of iq replies. See http://mail.jabber.org/pipermail/jdev/2014-January/089824.html and http://mail.jabber.org/pipermail/jdev/2014-January/089838.html for more discussion.
The iq.send function at https://github.com/fritzy/SleekXMPP/blob/develop/sleekxmpp/stanza/iq.py?source=c#L161 registers a handler to be called when a reply with the specified id comes in. However, it does not verify whether the from on the reply matches the to on the original iq. This makes it possible for attackers to spoof replies, for example spoofing vcards or intercepting file transfers.
I have verified that using the XEP 0092 (Software Version) plugin does indeed have this problem. self['xep_0092'].get_version(jid) will accept a reply that does not originate from the specified JID. Roster spoofing seems to be impossible, but there are many other iqs I didn't try.
Fix verifying 'from' for IQ results.
Closes issue #278
Thanks for the effort you've put into checking implementations, @xnyhps!
IQ senders are verified now, but I'm going to leave this open until I also get MAM sender verification checked.
Could this problem, related to resource binding to Facebook XMPP, be caused by this change?
From the log, it looks like Facebook's behavior is correct, though it is tricky to implement:
<iq type="result" from="-firstname.lastname@example.org" id="6e6fe59f-1683-41a9-9a32-dc8a952cdecd-2">
This reply informs SleekXMPP what its JID is, but because it changes the nodepart, it doesn't know yet that that reply is authorized. The reply is only authorized if it is handled first (which it isn't, because it appears unauthorized).
A workaround I heard from Swift (IIRC) is to consider any reply valid before a resource is bound, because malicious other's can't send you incorrect replies before you have bound a resource anyway.
Allow IQ processing based on only id value before the session is bound.
See issue #278
The Facebook issue should now be resolved in Sleek 1.2.4