moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

XEP-0313: Revision 0.6.1 (MUC message spoofing fix)

Browse Source
This commit is contained in:
Matthew Wild 2017-02-22 10:08:58 +00:00 committed by Sam Whited
parent 643f644091
commit 11e4febde5
1 changed files with 12 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
xep-0313.xml
View File

@ -27,6 +27,14 @@
</schemaloc> </schemaloc>
&mwild; &mwild;
&ksmith; &ksmith;
<revision>
<version>0.6.1</version>
<date>2017-02-22</date>
<initials>mw</initials>
<remark>
<p>Warn of spoofing of &lt;x&gt; elements in MUC stanzas</p>
</remark>
</revision>
<revision> <revision>
<version>0.6</version> <version>0.6</version>
<date>2017-02-17</date> <date>2017-02-17</date>
@ -531,7 +539,7 @@
<p>A MUC archive MUST NOT include 'private message' results (those sent directly between occupants, not shared in the room) in the results</p> <p>A MUC archive MUST NOT include 'private message' results (those sent directly between occupants, not shared in the room) in the results</p>
<p>A MUC archive MUST check that the user requesting the archive has the right to enter it at the time of the query and only allow access if so. In a members-only chat room, only owners, admins or members can query a room archive. In the case of open MUC rooms, the MUC archives can generally be accessed by any users (including those who have never entered the room) who do not have an affiliation of 'outcast', but a MUC archive MAY further limit access based on other criteria as part of the deployment policy. A MUC archive MAY, if it stores historical data about previous configuration states, limit the results returned to only those that the querying user would have been authorised to see at the time (e.g. it MAY limit the results to not include results while a user was an outcast).</p> <p>A MUC archive MUST check that the user requesting the archive has the right to enter it at the time of the query and only allow access if so. In a members-only chat room, only owners, admins or members can query a room archive. In the case of open MUC rooms, the MUC archives can generally be accessed by any users (including those who have never entered the room) who do not have an affiliation of 'outcast', but a MUC archive MAY further limit access based on other criteria as part of the deployment policy. A MUC archive MAY, if it stores historical data about previous configuration states, limit the results returned to only those that the querying user would have been authorised to see at the time (e.g. it MAY limit the results to not include results while a user was an outcast).</p>
<p>When sending out the archives to a requesting client, the 'to' of the forwarded stanza MUST be empty, and the 'from' MUST be the occupant JID of the sender of the archived message.</p> <p>When sending out the archives to a requesting client, the 'to' of the forwarded stanza MUST be empty, and the 'from' MUST be the occupant JID of the sender of the archived message.</p>
<p>In the case of non-anonymous rooms or if the recipient of the MUC archive has the right to access the sender real JID at the time of the query, the archive message will use extended message information in an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with a 'jid' attribute specifying the occupant's full JID, as defined for non-anonymous room presence in &xep0045;.</p> <p>In the case of non-anonymous rooms or if the recipient of the MUC archive has the right to access the sender real JID at the time of the query, the archive message will use extended message information in an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with a 'jid' attribute specifying the occupant's full JID, as defined for non-anonymous room presence in &xep0045;. The archiving entity MUST strip any pre-existing &lt;x&gt; element from MUC messages (as MUC rooms are not required to do this).</p>
<example caption='Server returns MUC messages'><![CDATA[ <example caption='Server returns MUC messages'><![CDATA[
<message id='iasd207' from='coven@chat.shakespeare.lit' to='hag66@shakespeare.lit/pda'> <message id='iasd207' from='coven@chat.shakespeare.lit' to='hag66@shakespeare.lit/pda'>
<result xmlns='urn:xmpp:mam:2' queryid='g27' id='34482-21985-73620'> <result xmlns='urn:xmpp:mam:2' queryid='g27' id='34482-21985-73620'>
@ -812,6 +820,9 @@
<section2 topic='Stanza IDs' anchor='security-stanza-ids'> <section2 topic='Stanza IDs' anchor='security-stanza-ids'>
<p>Entities that implement this specification must also adhere to the security requirements of XEP-0359.</p> <p>Entities that implement this specification must also adhere to the security requirements of XEP-0359.</p>
</section2> </section2>
<section2 topic='MUC message spoofing'>
<p>This specification re-uses the &lt;x&gt; element from the 'http://jabber.org/protocol/muc#user' namespace to convey information about the sender of a message in a MUC room. However this element is not sanitized by MUC services, so the archiving entity MUST strip any existing &lt;x&gt; element in the 'http://jabber.org/protocol/muc#user' namespace from messages before archiving them (regardless of whether it adds in its own &lt;x&gt; element).</p>
</section2>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>