Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`using` seems overly permissive #543

Open
philandstuff opened this issue May 12, 2019 · 2 comments

Comments

@philandstuff
Copy link
Collaborator

@philandstuff philandstuff commented May 12, 2019

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

This comment has been minimized.

Copy link
Contributor

@Gabriel439 Gabriel439 commented May 12, 2019

@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

This comment has been minimized.

Copy link
Collaborator

@singpolyma singpolyma commented May 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.