Hi,

while I see the general need for the added x Element in forwarded muc
messages. (I think i brought this up myself once in an earlier thread.)
This is missing a 'Security Consideration' that servers must remove the x
element if a users sends it. (In case the server is storing the entire
stanza and not just the Content of the body element.) Otherwise users can
very easily spoof messages as being from a different sender.

However the main problem is that even if the server removes those elements
as a client I still can't trust them because I don't know whether the
server has added the element or a malicious user.

I was always meaning to spark a conversation about server injecting
elements into stanzas that don't originate from them. (ejabberd for example
is already injecting the stanza-id (which don't get me wrong is a good
thing in theory.) The problem is not to sanitize those stanzas on the
server side the problem is that i don't know as a client.

I don't have a good solution to this yet and this should definitely go into
a different thread by maybe something about a special attribute for example
'by' that indicates who injected that tag and a general rule to remove all
elements that have the attribute by with my entity - or something.

cheers
Daniel

2016-01-20 18:27 GMT+01:00 XMPP Extensions Editor <[email protected]>:

> Version 0.5 of XEP-0313 (Message Archive Management) has been released.
>
> Abstract: This document defines a protocol to query and control an archive
> of messages stored on a server.
>
> Changelog: [See revision history] (XEP Editor (mam))
>
> Diff: http://xmpp.org/extensions/diff/api/xep/0313/diff/0.4.1/vs/0.5
>
> URL: http://xmpp.org/extensions/xep-0313.html
>
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: [email protected]
> _______________________________________________
>
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to