[Standards] XEP-0363: Restricted set of headers when requesting a slot

Jonas Schäfer jonas at wielicki.name
Tue Dec 15 14:49:13 UTC 2020


Hi Ivan,

On Dienstag, 15. Dezember 2020 02:56:33 CET Ivan Vučica wrote:
> I'm trying to direct the chat client to talk directly to the cloud
> storage API using 'signed URLs', granting time-restricted upload
> access to possessing a URL, where I can still restrict file size.
> 
> The cloud storage API happens to be Google Cloud Storage, but to my
> understanding, a similar approach applies to Amazon S3 and possibly
> other similar stores.
> 
> The XEP says (https://xmpp.org/extensions/xep-0363.html#request):
> 
> """
> The <put> element MAY also contain a number of <header> elements which
> correspond to HTTP header fields. Each <header> element MUST have a
> name-attribute and a content with the value of the header. Only the
> following header names are allowed: Authorization, Cookie, Expires.
> Other header names MUST be ignored by the requesting entity and MUST
> NOT be included in the HTTP request. The requesting entity MUST strip
> any newline characters from the header name and value before
> performing the HTTP request.
> """
> 
> I do understand that this tries to restrict the possible damage that a
> compromised server could direct a chat client to execute.

The rationale is about the same as for the existence of CORS rules. I think, 
back then (but I cannot find the specific discussion quickly) the choice was 
between forcing XMPP clients to fully implement the CORS standard or to define 
a specific set of headers.

The fact that being able to direct entities to send arbitrary HTTP PUT 
requests is a dangerous feat is known, otherwise CORS would not exist. So 
yeah...

> 
> However, this does mean setting useful custom headers such as
> x-goog-acl becomes difficult. (This particular header's documentation:
> https://cloud.google.com/storage/docs/xml-api/put-object-upload#request_head
> ers)
> 
> Two workarounds:
> - make the whole bucket public to the internet: in this particular
> case, feasible
> - on first GET access, update ACLs
>   - hopefully the API exists -- I did not actively seek it yet
>   - feasible because I want the permalink GET URLs to be on a domain I
> control - downside: this does cost a small amount of money
> 
> The best option is for the chat client to set this header to value
> "public" in order to make the blob visible to unauthenticated users.
> 
> This is only one cloud storage provider. It's not a lot of money to
> perform an extra write operation when the GET method is executed by
> the HTTP frontend (creating the 302 response). And clearly, this is a
> proprietary header. So -- it's not a big deal.
> 
> But, I do wonder what attacks are even possible if arbitrary PUT
> request headers are allowed. The user still has to attempt an upload,
> so this wouldn't be a large distributed attack.  What are the concerns
> with the upload component directing the user to an arbitrary service
> to perform the upload?

That’ll very much depend on the service we’re talking about. Mind that the 
XMPP client may live in a different trust zone than the server. It might be in 
an Intranet and might have access to other fun services which this allows to 
exploit in one way or another. Generally the same rationale why browsers 
forbid cross-domain requests (unless authorized via CORS), really.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20201215/047b9eb0/attachment.sig>


More information about the Standards mailing list