-
pep.
https://xmpp.org/extensions/xep-0363.html#request What's the rationale for limiting headers to these 3 only?
-
pep.
(Authorization, Cookie, Expires)
-
MattJ
pep.: to limit the evil that can be done by a server
-
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.✎ -
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. ✏
-
Zash
A server running on a LAN would return a LAN address...
-
pep.
evil server doing evil things via their client, through a quite small attack surface
-
pep.
So if tomorrow I need to pass Foo: bar because my server requires it, @#$% me?
-
jonas’
yes.
-
pep.
"640K is enough for everyone" ish
-
jonas’
the alternative would've been to depend '363 on CORS
-
jonas’
which nobody wanted
-
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
-
jonas’
which is what CORS is all about
-
jonas’
nobody wants CORS in XMPP
-
jonas’
hence, keep it simple
-
Zash
Just use the standard solution to all HTTP problems: Add another reverse proxy.
-
jonas’
how would that help?
-
jonas’
oh, the xmppd being one, yes
-
Zash
The proxy can add that header.
-
Zash
> So if tomorrow I need to pass Foo: bar
-
jonas’
or it could transform Cookie/Authorization to that header, indeed
-
Zash
or ?query stuff
-
jonas’
sure
-
jonas’
pep., also, given the number of stupid plastic routers and stuff like log4shell, I wouldn't consider the attack surface small.
-
pep.
Right so considering the server evil is now a norm I guess?
-
Zash
Meh
-
pep.
HTTP Upload again, multiple times the same header seems to be unspecified?
-
jonas’
in which way?
-
pep.
<put><header name="Authorization">Foo</header><header name="Authorization">Bar</header></put
-
jonas’
in which way does this need extra specification?
-
jonas’
forwarding both is perfectly valid in HTTP✎ -
Zash
Thanks to the wonders of HTTP, that is equivalent to `Authorization: Foo, Bar` except when it isn't
-
jonas’
including both is perfectly valid in HTTP ✏
-
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
-
pep.
Maybe it could also be hinted that http handles multiple headers just fine
-
pep.
"just fine" (I hear)
-
jonas’
"the server providing the headers will know what it's doing, eh"
-
Zash
If you control both the client and server, you can of course use forbidden headers all you want