[Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)

Jonas Wielicki jonas at wielicki.name
Sun Aug 5 10:59:18 UTC 2018


Hi all,

So while running the XEP-0060 node_config data form [1] through the thing 
which builds aioxmpp code to process it, I came across this funny field:

  <field var='pubsub#dataform_xslt'
         type='text-single'
         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
                engine'/>

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 
execution.


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.


kind regards,
Jonas

   [1]: https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-config
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180805/671997b6/attachment.sig>


More information about the Standards mailing list