Allow IP or range of IPs ?

[nico3333fr]

Hi there,

just a simple question: would it be possible to allow IP or range of IPs into CSP directives? Even if the case is not frequent, it might be possible to need this feature)

Kind regards,
Nicolas

[viki53]

Hi,

I have a not-so-uncommon use case for that, actually:

I work on an Ionic app with live reload on the phone, which uses some JS that's on my computer.

So, in order to execute that JS (which is helpful to trigger some reload when certain files have changed), my web page needs to allow scripts from certains IPs (to allow this CSP to work accross all devices, even on my colleagues' computers).

I have tried many masks, such as 192.168.1.*, 192.168.*… even *.192.168.1! But nothing worked, so I end up commenting the meta tag every time I need to use live reload on my phone, which is kind of like a hemorroid…

[shekyan]

@nico3333fr what would be the use-case that cannot be resolved with domain names?

@viki53, IP addresses in source expressions are ignored, except if IP address is 127.0.0.1 , see 6.1.11.4. Does url match expression in origin with redirect count?, section 5.
The best approach for you would be to resolve a domain name to that IP (through hosts file, local DNS, whatever), then whitelist the domain name.

[viki53]

Host files would be impossible to manage, considering there's a bunch of IPs and devices that we use (plus, changing smartphones hosts files isn't always easy).

Smae with DNS: we'd need a subdomain for each computer, which can change IP on a regular basis… and someone to maintain the DNS server.

That's why allowing IPs would be useful. Also, some people don't have domain names but work with static IPs. That's also a usecase.

[shekyan]

Perhaps, for such cases we can introduce "unsafe-local" keyword for source expression, that would allow resources from any non-routable IPs, but will have effect only if "'self'" origin resolves to a local IP address?
Although I am not convinced it is necessary:(

[viki53]

I agree it's mostly for development purposes, so maybe not a huge improvement, but it can be really tricky to handle this kind of thing without a ton of specific development.

That kind of keyword would be great and would make it even easier, although I don't know what the behavior would be like in companies with firewalls and proxies everywhere (not my case, so I can't really imagine).

[mikewest]

This isn't something I want to add to CSP, as IP addresses simply do not have the same security properties as named hosts. I have workarounds for you, however:

For development, something like http://xip.io/ (perhaps something similar that you run on your local network) is a pretty reasonable approach that allows you to grant access to particular IP addresses. I'd prefer to keep IP addresses out of the syntax as is, and encourage folks to have authenticated names for the sources of resources they're loading in the wild.

Alternatively, 'nonce-...' and 'sha256-...' (which now can allow external files in conjunction with SRI) seem like reasonable solutions (also for production use).

[ddworken]

Reviving a quite old thread, but we recently ran into a case at Google where it would arguably be useful to support IP addresses in host allowlists. We're currently working on deploying what we call "fine-grained CSP allowlists" at Google where we're creating CSP headers that enumerate the specific URLs of all included JS subresources. These CSP policies are not meant to act as an XSS mitigation (we're still relying on a separate strict nonce-based CSP for this) but are instead meant to give us a concrete enumeration of JS resources included by a given app.

Currently, if an app is hosted on an IP address and includes JS subresources from a relative path (e.g. http://127.0.0.1/index.html includes /foo.js) it isn't possible to have a fine-grained allowlist that allows this. The best we can currently do is allow self, but this is broader than our usual fine-grained allowlist entries.

In practice, this isn't a huge issue for us since hosting apps on IP addresses is quite rare (it mainly comes up in the context of development environments). But I think it is a reason that it could be nice to allow matching on IP addresses.

[tomrittervg]

re instead meant to give us a concrete enumeration of JS resources included by a given app

I think the thing you want for that is report-hash which is actively being worked on.

[ddworken]

re instead meant to give us a concrete enumeration of JS resources included by a given app

I think the thing you want for that is report-hash which is actively being worked on.

That doesn't quite give us what we want for our use case, since our goal is to enforce a list of allowed scripts (many of which may change over time). So we could use report-hash to collect information about scripts, but it wouldn't give us enforcement. Alternatively we could use a hash-based CSP, but that wouldn't support the fact that scripts change over time. So for our use case, these fine-grained URL allowlists really are the best fit.

Though I won't deny that this is a somewhat niche use case, and that adding support for IP addresses isn't that high of a priority FR.