[Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)
jonas at wielicki.name
Sun Aug 5 10:59:18 UTC 2018
So while running the XEP-0060 node_config data form  through the thing
which builds aioxmpp code to process it, I came across this funny field:
label='The URL of an XSL transformation which can be
applied to the payload format in order to generate
a valid Data Forms result that the client could
display using a generic Data Forms rendering
I was at first confused, but then figured out that this is an XSLT which can
be applied to the payload in the node items to extract a XEP-0004 Data Form
which is then renderable. At least that’s what I think. There’s no text which
describes its use in more detail.
So, I have a few questions:
1. So this looks as if we recommend clients to download a piece of code in a
turing-complete language, execute it on random content and then render the
result as a Data Form without mentioning that in the Security Considerations.
Do we *really* want that?
2. Do we know of a use-case for that which warrants to have this in XEP-0060
itself as opposed to separate extensions?
- It seems to me that it is a very bad idea for clients to obtain a XSLT and
execute it on data and then show the form to the user just because a message
looks like a pubsub payload.
- Given that, a client which would contemplate applying the XSLT would
already have to be familiar with the broad type of pubsub payload it is seeing
(because it won’t do that for arbitrary pubsub payloads, of course).
- Given that, it is likely that some type of PubSub based protocol is
involved. It would make sense to simply specify in that protocol how to derive
the Data Form instead of making the clients vulnerable to remote code
If the answer to the first question is "no", I propose that we add a section
to the security considerations which goes over the following issues:
- Don’t execute XSLT from untrusted sources
- Mention that just because a payload looks like a familiar protocol, the
sender could still be malicious; so the "trust" check needs to happen based on
the @from and possibly the publisher.
- Mention that the @from/publisher can be spoofed by the pubsub service and
the users own server.
If the answer to both questions is "no", I suggest to simply drop this field
out of the form, and/or if that is too harsh for Draft, modify the label/
description to actively discourage its use and implementation (i.e. Deprecate/
Obsolete this part of the XEP, just like we did with XEP-0071 (XHTML-IM)).
Note, there is another field (pubsub#body_xslt) which has similar issues, but
is supposed to execute on the pubsub service instead of the client. I think
the text motivates its existence to a certain degree, but at least the
security considerations need to be mentioned.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards