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

Restrict to proxy controllers to external servers #28439

Merged
merged 23 commits into from Jun 19, 2019

Conversation

sureshc
Copy link
Contributor

@sureshc sureshc commented May 8, 2019

Prevent Media Proxy and other proxy controllers from being used to communicate to internal servers.

Copy link
Member

@davidsbailey davidsbailey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

currently, "code.org" is whitelisted in the xhr proxy controller, and some apps (perhaps some curriculum?) depend on applab apps being able to use this to read data from each other. Will this change break this behavior?

in security, allow-lists are typically preferred over deny lists. is there a way to assert positively that a request is going to some place outside our network rather than trying to list all of the ways that it could be going somewhere inside?

@@ -147,4 +160,11 @@ def render_error_response(status, text)
prevent_caching
render plain: text, status: status
end

# Do not permit proxying to a server on our own private network, unless it is our own dashboard IP Address (we
# sometimes proxy to ourselves, which is an internal IP address on development / continuous integration environments).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we still need this exception allowing our own dashboard IP address, given the comments elsewhere that this is only enforced in production?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've eliminated the production-only logic in favor of a more narrow exception that allows proxying to a private IP address when that is the IP address that the current dashboard server is operating on.

@sureshc
Copy link
Contributor Author

sureshc commented May 16, 2019

currently, "code.org" is whitelisted in the xhr proxy controller, and some apps (perhaps some curriculum?) depend on applab apps being able to use this to read data from each other. Will this change break this behavior?

code.org resolves to a public address, so proxying to it is allowed and not impacted by this change.

in security, allow-lists are typically preferred over deny lists. is there a way to assert positively that a request is going to some place outside our network rather than trying to list all of the ways that it could be going somewhere inside?

As best as I can tell, the formal definition of a public IP address, is any IP address that is not reserved for private/local use. I've tried to use a method name that is consistent with the practice of defining allow-lists (allowed_ip_address?), but the logic within that method needs to check the inverse, that the IP address is not a private/reserved address as defined by the IANA.

Copy link
Member

@davidsbailey davidsbailey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for responding with well-thought-through answers! LGTM!

Copy link
Contributor

@wjordan wjordan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM, see comment about potential simplification.

IPAddr.new('169.254.0.0/16'),
IPAddr.new('192.168.0.0/16'),
IPAddr.new('fd00::/8')
].freeze
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this check could be simplified to ip.private? || ip.link_local? || ip.loopback? || IPAddr.new('0.0.0.0/8').include?(ip), which would offload some of these details to the Ruby standard lib.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't notice those handy methods. Switched to using them!

@sureshc sureshc requested a review from wjordan June 19, 2019 16:44
@sureshc sureshc merged commit d10563f into staging Jun 19, 2019
@sureshc sureshc deleted the restrict-proxy-from-private-network branch June 19, 2019 22:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants