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

Add HMAC/IP support for different remote IP's through proxies & Cloud… #49

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

PauluzzNL
Copy link

The library's default is to have the HMAC IP check enabled. This gives issues with sites that run through CloudFlare as the remote IP that CloudFlare connects from is different through requests. Thus this could result in an invalid request already if you have a page open for 2 minutes.

The added functionality adds support for the CloudFlare connecting IP and other commonly used proxy methods. With these changes you can continue to use the HMAC check through CloudFlare/proxies.

if (isset($this->server["HTTP_X_FORWARDED_FOR"]) && filter_var($this->server["HTTP_X_FORWARDED_FOR"], FILTER_VALIDATE_IP))
{
return $this->server["HTTP_X_FORWARDED_FOR"];
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Attackers can lie about X-Forwarded-For. This should be guarded by a configuration setting.

Copy link
Author

Choose a reason for hiding this comment

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

What would you suggest? A configuration setting as in hmac_ip_allow_x_forwarded_for? Or something more general that would include both this option as well as CloudFlare for example?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, a configuration setting would be a good idea. Let people opt into this behavior.

{
if (isset($this->server["HTTP_CF_CONNECTING_IP"]) && filter_var($this->server["HTTP_CF_CONNECTING_IP"], FILTER_VALIDATE_IP))
{
return $this->server["HTTP_CF_CONNECTING_IP"];
Copy link
Contributor

Choose a reason for hiding this comment

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

What if an attacker specifies a fake header here after discovering the server's real IP?

What if an attacker specifies this header for a non-CloudFlare IP?

Etc.

Copy link
Author

Choose a reason for hiding this comment

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

Would you suggest validating against the REMOTE_ADDR to the CloudFlare IP ranges? https://www.cloudflare.com/ips/

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, and this can be hard-coded. We can update it in the future if their list of IPs widens.

@PauluzzNL
Copy link
Author

@paragonie-security I've thought about your suggestion and played around a bit but I think there's several approaches that I wanted to check with you first.

Especially for the IP filtering for CloudFlare, there's multiple options:

  • additional code that blows up the framework for IP validation and range checking
  • add an external dependency to validate the IP address ranges such as https://github.com/mlocati/ip-lib which can be included with composer and has no other external dependencies
    -> in both of the above we could also choose to put the cloudflare ip's in a txt file with a quick command to update the file to the latest list fetched from CF

or

  • make this a configuration option and leave out the validation as well

in that case there's also two options:

  • create 1 configuration option to include deeper layer remote ip's (that enables CF, HTTP X FORWARDER FOR, HTTP_CLIENT_IP
    or
  • create multiple options for the different checks

Could you share with me your preferences?

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.

2 participants