Dhall-lang: `using` seems overly permissive

[philandstuff]

The using feature allows an import to supply arbitrary HTTP headers to another import. However, this feels like it could subvert security mechanisms in place. For example, if two different HTTP hosts share the same IP address (which might commonly happen for different services sharing a CDN or hosting provider), it might be possible to bypass the CORS check and fetch a sensitive resource http://innocent-victim.com/prize with something like:

http://attacker-controlled-origin.com/prize using http://attacker-controlled-origin.com/badheaders

where the badheaders sets a header of Host: innocent-victim.com. From dhall's point of view, all the requests went to the attacker's origin, so CORS passes correctly. However, the http server sees a Host header value matching the victim's origin, so the server presents the victim's data.

This particular attack might not seem interesting at first because nothing browsable on the public internet without cookies or other credentials will be sensitive, and Dhall doesn't maintain a cookie jar of credentials for the user. I don't think I've got a working exploit here, but I think this example at least demonstrates the point that certain request headers are sensitive and changing them can violate security assumptions.

The CORS spec has a list of forbidden header names which clients are not allowed to set for this reason. We could try to implement this forbidden header list.

Perhaps controversially, I'd be inclined to explore removing using from the language. It's not well documented, and I believe its intended purpose (requesting things that require credentials?) could be achieved through other means, such as providing explicit access to the Authorization header rather than blanket access to all possible request headers, or encouraging users to use ~/.netrc to manage credentials for sensitive resources (and potentially implementing CORS checks for requests-with-credentials to prevent other origins snooping on them).

[Gabriel439]

@philandstuff: I believe the main use case for the using header is accessing private repositories (i.e. private GitHub/GitLab, for example), so while ~/.netrc might not be a suitable replacement, providing limited support for the Authorization header might be fine.

One way we could do this is that instead of blacklisting headers, we can whitelist only authorization-related headers (i.e. Authorization/Proxy-Authorization as far as I know).

[singpolyma]

Since CORS contacts remote server will the check not use the Host header anyway?

[sjakobi]

FWIW, using has been causing us some headaches in the Haskell implementation (e.g. https://github.com/dhall-lang/dhall-haskell/issues/1925, https://github.com/dhall-lang/dhall-haskell/pull/1951#issuecomment-665720763). So getting rid of that feature seems like a good idea to me.

[Gabriel439]

Yeah, I would vote in favor of a proposal to remove support for removing the using keyword. All we really need is a migration plan explaining what alternative users should prefer