[Standards] XMPP Council Minutes 2018-06-20
georg at op-co.de
Mon Jul 2 07:47:36 UTC 2018
* Sam Whited <sam at samwhited.com> [2018-06-24 17:19]:
> On Sat, Jun 23, 2018, at 06:24, Tedd Sterr wrote:
> > 3) Advance XEP-0363: HTTP File Upload
> > Georg: [pending]
> A few notes on the security section:
> - I wonder if it's worth either specifying that content-type sniffing by the client is not allowed, or that the X-Content-Type-Options header  is allowed on the server and should be respected by the client
> - Maybe explicitly say what to do with executable content types
> - We may want an overview of other common security headers
These are excellent points. Allowing users to upload HTML/JS or any
other active content that might be executed on the server or in the
client automatically, giving the uploader access to the user's security
domain (e.g. session cookies from the web xmpp client or a logged-in
session into the xmpp server's account interface) is a valid scenario,
and we should at least clearly say that this is a problem, and maybe
even reference to some best practices regarding securing that. I'm not
sure we should explicitly define the counter-measures in the XEP,
because the web and it's attack vectors are moving very fast, compared
to our processes, and we would inevitably end up with stale / bad
> Otherwise I'm still unsure about limiting what headers can be set and
> still think we need a generic way to do this. Lots of services include
> non-standard auth headers, for example.
I'm not sure we actually need to support those lots of services for
purposes of XMPP HTTP upload. IMHO, even those three headers listed (and
the generic <header name=''/> format that will probably lead to clients
not actually filtering on the whitelist) are already making the "simple"
protocol needlessly complicated. If you want to use a custom service
that requires custom auth headers, put a proxy in front of it?
+1, if we add a clear statement about potentially malicious uploads
running in the context of your web server / domain.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards