IP whitelisting is not possible from host server

[ghost]

I'm trying to whitelist an IP address from the host web server, however I am unable to do so, due to some novel IP address configuration on the server itself. It logs that the traffic is coming from the IP address of the server rather than the loopback address 127.0.0.1.

Is it possible for the IP whitelisting to include the IP address of the server itself? It doesn't look like this is stored in DNN, but it looks like you are able to get it from ASP.NET.

We will need to be certain that the source of IP address cannot be compromised as this would be exploitable.

[bdukes]

In https://github.com/cantarus/PolyDeploy/blob/78b6127ae1ea8200c8ef1ea233ac6b0d84461535/PolyDeploy/Components/WebAPI/ActionFilters/InWhitelist.cs#L46, consider using HttpRequestBase.IsLocal instead of checking 127.0.0.1

[tomwalters]

@can-martin-kennish This is likely caused because the server is behind a reverse proxy, thus obscuring the real IP. Is there a way we could inspect the headers to extract an X-Forwarded-For?

There might be some security considerations to make around IP spoofing when doing a direct comparison to 127... so the solution from @bdukes is probably the best bet (although I wouldn't be surprised if the actual implementation is exactly the same.)

[ghost]

@tomwalters It's not a reverse proxy issue, PolyDeploy has handling for this already built in.

The scenario this occurred in was where the web server had multiple IP addresses bound to it. So it appeared the traffic was coming from one of those rather than the localhost loopback address.

[bdukes]

The basic logic for IsLocal is in HttpWorkerRequest

[ghost]

Thanks @bdukes, I'll make the change and see if it resolves the issue we're having in the environment @can-martin-kennish described above.

[RichardHowells]

The scenario this occurred in was where the web server had multiple IP addresses bound to it. So it appeared the traffic was coming from one of those rather than the localhost loopback address.

I just installed v0.9.3

I found the same problem as mentioned above on a machine with multiple IP addresses. It is no longer easy to hack IP addresses into the database as they are no longer stored in human readable form.

I used the following workaround, which is somewhat complex and a PITA...

• Add another IIS binding for https://127.0.0.1
• Add a portalalias for https://127.0.0.1

Then I was able to get to the site using 127.0.0.1 and access the UI for setting up WhiteLists and API Keys.

The machine I am using has multiple installs of DNN and most of the installs have multiple portals. In this situation my workaround is fairly painful.

@can-anierzad - did the change you refer to actually get made? If so it does not seem to help in my situation.