On 11 October 2017 at 21:42, Sam Whited <[email protected]> wrote: > Hi all, > > I recently tried out another service that supported XEP-0071: XHTML-IM > [1]. Like all other web-based services with XHTML-IM support that I've > tried, it was vulnerable to a trivial script injection. When I say > "all", I really do mean "all" (though I'm not sure how many; it's more > than a few at this point). I have yet to find a web-based service that > supports XHTML-IM that was not either vulnerable to remote script > execution when I tried it, or had not been vulnerable in the past. I am > not saying that they don't exist, but I have tried a number of clients > and services and I haven't found one yet (I'm specifically talking about > things that use web browsers; I'm sure there are clients which use > libraries like GTK's limited HTML support where there isn't a JavaScript > engine available and therefore it's impossible to execute a script). >
I would note that in principle, a content security policy ought to prevent such attacks outright. But there would, probably, remain several other innovative attacks, such as passing client-specific markup intended to duplicate existing UI elements. > In one sense, the spec is not to blame for this. It does things > correctly, utilizing a white list of attributes and elements, and if you > follow it you are likely to be safe from injection. In the real world > though, this is not enough. Using HTML ina browser, even when done > right, ties you to an environment that can execute scripts meaning that > small bugs have a higher potential to end up causing a security issue > (this is what I observed in the case of one large commercial service > provider where a simple error in their whitelist implementation allowed > arbitrary script execution). Furthermore, the "path of least resistance" > for developers is just to dump HTML into the DOM, which I have observed > on a number of web clients, including the one I ran into recently that > prompted me to write this. > > I'd like to suggest (again) that we obsolete XHTML-IM. If the easy way > to implement a spec is insecure, you can be sure users will do that. We > can't guarantee security in a spec, but we can certainly make something > that's harder than XHTML-IM to implement incorrectly, which would be a > huge gain. > There are dozens of quite reasonable Markdown libraries in Javascript. These will handle, suppress, and otherwise deal with embedded HTML. Every other IM system I can find just does Markdown of some flavour. XHTML is, pretty much, dead at this point anyway. So overall, I think we should move rich IM formatting to Markdown and call it done. > There is an argument to be made that we should create a replacement > first, but since this is a security issue and not just a sub-optimal > spec, I beleive that it would be irresponsible for the XSF to continue > to recommend this spec given the number of bad implementations we've > seen over the years and we should obsolete as quickly as possible. > > Thoughts? > > —Sam > > [1]: https://xmpp.org/extensions/xep-0071.html > > -- > Sam Whited > [email protected] > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
