Re: [Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)
[replying on-list] On 8/7/18 12:37 PM, Jonas Wielicki wrote: > On Dienstag, 7. August 2018 18:28:45 CEST you wrote: >> On 8/5/18 4:59 AM, Jonas Wielicki wrote: >>> 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: >>> >> >>> 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. >> >> It seems to be a data forms result, not a form one would fill out. > > Ahh, that makes slightly more sense. > >>> At least that’s what I think. There’s no text which >>> describes its use in more detail. >> >>> So, I have a few questions: >> A simpler question: is anyone using this feature? >> >> I doubt it, and I'd be inclined to remove it. > > Me too. > > However, even if we decide to keep it, and even if the XSLT is actually > supposed to be executed on the server side of things, the security issues of > that *very much* need to be documented. I'm suggesting we delete the feature - most likely it was something we thought might be useful someday, which turned to be false (leaving aside the many security issues!). Peter signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)
On 8/5/18 4:59 AM, Jonas Wielicki wrote: > 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: > > 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. It seems to be a data forms result, not a form one would fill out. > At least that’s what I think. There’s no text which > describes its use in more detail. > > So, I have a few questions: A simpler question: is anyone using this feature? I doubt it, and I'd be inclined to remove it. Peter signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)
Executing arbitrary code on the client? Kill it with fire! I'd guess this is a case of trying to be overly-flexible in the hope of covering all possible unspecified use-cases. I wouldn't even expect that most clients can execute XSLT. And if the aim is to generate a data-dependent form, is there a reason the form couldn't be generated server-side first? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)
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: 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 signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
