[PATCH cube signedrequest] Support new protocol version for signed requests coming from a browser

Laurent Wouters lwouters at cenotelie.fr
Fri Jun 21 09:23:04 CEST 2019


>> The current protocol for signed request requires the use of the Date HTTP
>> header. Although this works fine for clients that have full control over the
>> HTTP headers they send, this is not working in the context of web browser where
>> the Date HTTP headers are forbidden to be programmatically set (and therefore
>> used in any meaningful way)
>> https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
> I'm a bit surprised that one may want to allow an application to use
> signed requests from the browser. Can't this be achieve through proper
> CORS configuration? Can you provide more details on the intended usage?


The intended use case is be able to execute requests to a cubicweb
instance from a third site. For example, the cw instance is accessible
at mydomain.com but my third web application is served from other.com
(the client is making the requests). In this scenario, CORS indeed need
to be correctly configured, but the problem I was facing was that the
cookie handling authentication for cubicweb at mydomain.com is tagged
with samesite
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies),
thus preventing it being sent by the browser from a web application
served from other.com.

Maybe there is a simpler solution, but I did see it.


>> To avoid this issue, this changeset introduces a new protocol version that use
>> custom HTTP headers (X-Cubicweb-Foo) for non-standard, or otherwise forbidden
>> HTTP headers. Instead of a date, this version of the protocol relies on the
>> client generating a cryptographically-secured nonce that is passed in a header
>> and included in the signature computation.
> I think we'll need a bit more details on the security aspects of this
> proposal. I'd, for one, appreciate any kind of external references
> demonstrating that this is a good practice.


Well, according to this draft from the IETF
(https://tools.ietf.org/id/draft-cavage-http-signatures-08.html), it
looks like the Date HTTP header SHOULD be used (noted in § 2.3) so we
should try to keep it that way. Also in §3, it is noted that there is
indeed an assumption that the client is able to send a Date header ...

It looks like that amazon supports a custom header for dates
(x-amz-date) precisely for this scenario :
https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
at § Time Stamp Requirement.

So would you think a solution of simply allowing a X-Cubicweb-Date
header as an alias for Date when it is not present would be OK ? I think
this solves the above problem and keeps the current protocol
quasi-unchanged.

Laurent





More information about the cubicweb-devel mailing list