jdev - 2021-12-27


  1. pep.

    https://xmpp.org/extensions/xep-0363.html#request What's the rationale for limiting headers to these 3 only?

  2. pep.

    (Authorization, Cookie, Expires)

  3. MattJ

    pep.: to limit the evil that can be done by a server

  4. MattJ

    The server can return any address for the upload, including things like LAN addresses. Some HTTP security flaws can be performed through header manipulation.

  5. MattJ

    The server can return any address for the upload, including things like LAN addresses. Some HTTP implementation security flaws can be exploited through header manipulation.

  6. Zash

    A server running on a LAN would return a LAN address...

  7. pep.

    evil server doing evil things via their client, through a quite small attack surface

  8. pep.

    So if tomorrow I need to pass Foo: bar because my server requires it, @#$% me?

  9. jonas’

    yes.

  10. pep.

    "640K is enough for everyone" ish

  11. jonas’

    the alternative would've been to depend '363 on CORS

  12. jonas’

    which nobody wanted

  13. jonas’

    because you need to get consent from the receiving domain that the "sending" domain (your XMPP server) is allowed to formulate a request (via the client) to that domain

  14. jonas’

    which is what CORS is all about

  15. jonas’

    nobody wants CORS in XMPP

  16. jonas’

    hence, keep it simple

  17. Zash

    Just use the standard solution to all HTTP problems: Add another reverse proxy.

  18. jonas’

    how would that help?

  19. jonas’

    oh, the xmppd being one, yes

  20. Zash

    The proxy can add that header.

  21. Zash

    > So if tomorrow I need to pass Foo: bar

  22. jonas’

    or it could transform Cookie/Authorization to that header, indeed

  23. Zash

    or ?query stuff

  24. jonas’

    sure

  25. jonas’

    pep., also, given the number of stupid plastic routers and stuff like log4shell, I wouldn't consider the attack surface small.

  26. pep.

    Right so considering the server evil is now a norm I guess?

  27. Zash

    Meh

  28. pep.

    HTTP Upload again, multiple times the same header seems to be unspecified?

  29. jonas’

    in which way?

  30. pep.

    <put><header name="Authorization">Foo</header><header name="Authorization">Bar</header></put

  31. jonas’

    in which way does this need extra specification?

  32. jonas’

    forwarding both is perfectly valid in HTTP

  33. Zash

    Thanks to the wonders of HTTP, that is equivalent to `Authorization: Foo, Bar` except when it isn't

  34. jonas’

    including both is perfectly valid in HTTP

  35. pep.

    I just realized it's written nowhere that one must forward headers to the put url, I think. It's written that one must ignore other headers and must not include them in the http request

  36. pep.

    Maybe it could also be hinted that http handles multiple headers just fine

  37. pep.

    "just fine" (I hear)

  38. jonas’

    "the server providing the headers will know what it's doing, eh"

  39. Zash

    If you control both the client and server, you can of course use forbidden headers all you want