[Standards] Security issues with XHTML-IM (again)

Sam Whited sam at samwhited.com
Wed Oct 11 20:42:45 UTC 2017

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

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



[1]: https://xmpp.org/extensions/xep-0071.html

Sam Whited
sam at samwhited.com

More information about the Standards mailing list