XSF Discussion - 2023-11-22


  1. larma

    1. We can also just add random padding of random length into stanzas. Doesn't need to be a lot to make length based analysis extremely hard 2. I personally would prefer to replace XML with a binary encoding (like EXI, but a bit simpler) that has support to "compress" certain data types (numerics, base64, UUIDs, hex-encoded) by encoding them in binary. Plus doing this together with length-prefixes can greatly improve parsing performance. That way we don't suffer from any of the issues typically caused by compression. It will leave a lot of strings uncompressed though

  2. larma

    1. We can also just add random padding of random length into stanzas (in addition to per-stanza compression instead of full stream). Doesn't need to be a lot to make length based analysis extremely hard 2. I personally would prefer to replace XML with a binary encoding (like EXI, but a bit simpler) that has support to "compress" certain data types (numerics, base64, UUIDs, hex-encoded) by encoding them in binary. Plus doing this together with length-prefixes can greatly improve parsing performance. That way we don't suffer from any of the issues typically caused by compression. It will leave a lot of strings uncompressed though

  3. singpolyma

    An end to end solution for the base64 situation would be great, mostly because of stanza size limit probablems

  4. deimos

    I am once again telling you, xmpp works in the deep woods with barely any signal, whereas every other chat protocol is failing to connect, nevermind login.

  5. deimos

    bernie sanders endorses this message

  6. deimos

    😉

  7. t4d

    lol

  8. jonas’

    larma, writing down such a simplified EXI would be a nice exercise and can probably be done. one might even build on existing binary formats (msgpack? protobuf?) and simply define a DOM<->$thatFormat

  9. jonas’

    larma, writing down such a simplified EXI would be a nice exercise and can probably be done. one might even build on existing binary formats (msgpack? protobuf?) and simply define a DOM<->$thatFormat mapping

  10. MattJ

    deimos [07:21]: > I am once again telling you, xmpp works in the deep woods with barely any signal, whereas every other chat protocol is failing to connect, nevermind login. And that's without FAST, compression, etc. It can only get better 🙂

  11. Daniel

    I was testing the sasl2 / bind2 implementation in ejabberd yesterday and I can once again confirm that it is in fact very fast

  12. MattJ

    🎉

  13. debacle

    fast or FAST?

  14. Zash

    F.A.S.T.

  15. Guus

    Making it sound like an 80's kids show.

  16. Guus

    is there documentation on how to process XMPP-exchanged text to avoid things like HTML injection, etc?

  17. jonas’

    ... don't interpret it as HTML?

  18. jonas’

    usually that's an extra step, unless you're in javascript in a webbrowser which has the innerHTML footgun.

  19. Guus

    exactly that, but in nicer words :)

  20. Guus

    I know we have some 'best practices' texts, I was hoping this was mentioned elsewhere.

  21. jonas’

    I... I don't even know how to put this :)

  22. Guus

    Now you know why I

  23. Guus

    I'm asking.

  24. jonas’

    I mean, how to put this family friendly

  25. singpolyma

    If it's just the body text there is no html there. So just treat it as plain text and you'll be fine

  26. Guus

    didn't we have a bunch of this when we were discussing if to bin the HTML markup thingy XEP that we had?

  27. singpolyma

    Yes, dhere are things to consider for xhtml-im, but not for plain text body

  28. jonas’

    correct

  29. jonas’

    (and Guus specifically said "text", so I was assuming it's not XEP-0071-related)

  30. jonas’

    (in which case the story is much more complex, as you need to somehow sanitize whatever's going on in the HTML)

  31. Guus

    well, one thing is to not process plain text body as HTML, obviously - but apparently, that's not obvious to client developers, and thus, I was hoping for pre-existing guidelines on this.

  32. jonas’

    > but apparently, that's not obvious to client developers thank you I did not want to know that

  33. Guus

    some* client developers

  34. jonas’

    same

  35. jonas’

    Guus, what would such pre-existing guidelines change?

  36. jonas’

    I have a problem believing that someone who stuffs attacker-controlled text into innerHTML in javascript would read any security best-practice document.

  37. Guus

    It'd be a good thing for me to point at while discussing this with them

  38. jonas’

    ah.

  39. jonas’

    I see.

  40. Guus

    "there - follow that for the reasons stated!"

  41. jonas’

    Guus, on which level of detail would that be?

  42. Guus

    That of a client developer

  43. jonas’

    a generic client developer?

  44. jonas’

    or a javascript client developer?

  45. jonas’

    (because gtk may also interpret some HTML in text if you feed it the wrong way)

  46. jonas’

    and if we start to be specific about frameworks and languages, the amount of work and the risk of going out-of-date increases.

  47. Guus

    What I have found with a good deal of my customers is that whatever frontend developers they have, implement the XMPP client as a side-product of a larger system. So they're often not very well versed in XMPP.

  48. jonas’

    on the other hand, if we just write "well, that's attacker controlled text. Don't put it into anything where it may do harm.", that's probably not really helpful.

  49. jonas’

    this has absolutely nothing to do with XMPP in my opinion.

  50. jonas’

    you don't just put attacker-controlled or any remote input into innerHTML, period.

  51. jonas’

    that's web front-end security 101.

  52. Guus

    Yeah, you're right

  53. Guus

    still, it happens. :)

  54. Guus

    but you're right, it's not very XMPP specific

  55. jonas’

    we do have security considerations in many documents for XMPP-specific stuff, but ... I don't know, if we start to assume that the readers of our specs are not well-versed in basic, not-XMPP-specific security, I fear we'll be getting nowheer.

  56. jonas’

    we do have security considerations in many documents for XMPP-specific stuff, but ... I don't know, if we start to assume that the readers of our specs are not well-versed in basic, not-XMPP-specific security, I fear we'll be getting nowhere.

  57. jonas’

    you may want to instead find a web front-end security 101 book or whatever for them.

  58. jonas’

    what we could do is to make a list of things which can reasonably be trusted in XMPP, iff you trust your server. Such as @to/@from/@type. And that's about it.

  59. jonas’

    and then tell people to put limits and escaping on literally everything else, which would be a good call.

  60. jonas’

    but that doesn't free them from having to read and understand basic security practices in the frontends and tooling they're working with

  61. Guus

    I'm in agreement.

  62. jonas’

    but that doesn't free them from having to read and understand basic security practices in the frameworks and tooling they're working with

  63. Zash

    jonas’, hold on let me just `/nick <script>alert("lol");</script>`

  64. jonas’

    Zash, uff

  65. jonas’

    yeah, don't trust anything.

  66. moparisthebest

    one rule for networking applications: 1. Never trust remote data

  67. jonas’

    but fair point

  68. Zash

    mixing stuff from different origins needs to be done very carefully</body></message>'; DROP TABLE "messages"; --

  69. Guus

    Thank you for not using Openfire's default database table name in that example :D

  70. singpolyma

    Guus: you might want to suggest they use React or something else that will handle this sanely for them, but I dunno

  71. moparisthebest

    oh no you've brought down the wrath upon us... I've been watching a fediverse fight lately where 99% of participants say react is "anti-web" but never state reasons, hope they don't find us 😰

  72. Guus

    singpolyma: this is far from a new project...

  73. singpolyma

    Oh for sure, react is anti web, but so is any XMPP rich client made in javascript anyway :P

  74. singpolyma

    Guus: fair enough. "Use textContent to set text"

  75. Guus

    Which is a concise way of telling what I've told them :)

  76. Guus

    (it started with them asking me to create a server plugin to filter stuff like this...)

  77. Zash

    Filter what?

  78. Zash

    Sanitize XHTML-IM?

  79. Guus

    Plain text, even.

  80. singpolyma

    > (it started with them asking me to create a server plugin to filter stuff like this...) ouch

  81. Zash

    Filter plain text ... for what, HTML?

  82. singpolyma

    yes

  83. singpolyma

    because they are taking the plain text body and stuffing it into innerHTML

  84. singpolyma

    which will just break for all kinds of reasons, it's not just a security problem

  85. Zash

    Fire them. Now. Retroactively even.

  86. Guus

    Hey, I'm pretty much turning down paid work for them to fix things on their end. :)

  87. Guus

    Is 'Reporting Account Affiliations' still in inbox?

  88. Trung

    I think xhtml is cool coz it has enuf elements to style

  89. Trung

    Or xhtml-im

  90. Trung

    Or xhtml-im

  91. Trung

    And there's no `<script>`

  92. edhelas

    I should be there this year at the FOSDEM :)

  93. edhelas

    *next year

  94. emus

    👍