Developer forum

Could they be use some sort of proxy on their net. x-forwarded-for header vs. the IP?

Could they be use some sort of proxy on their net. x-forwarded-for header vs. the IP?

Havin an IPv6 in their banned IPs is very odd as there should not be ipv6 on their webserver. That could indicate that they internally run ipv6, and that is forwarded in a header DW understands...

Hi Nicolai,

I'll see if I can meet with the customer and through screen sharing try to capture more information. If you have any other ideas on how I could even capture this, I'd appreciate it.

In regards to the IPv6 (which may or may not be related), here's what we're seeing

Cloudflare configuration issue? ipBanner is looking at x-forwarded-for headers - and they could contain something that DW misunderstand...

I guess this kind of request is not coming from inside their organisation

/products?ProductType=2%27%29+AND+1%3D1+UNION+ALL+SELECT+1%2CNULL%2C%27%3Cscript%3Ealert%28%5C%22XSS%5C%22%29%3C%2Fscript%3E%27%2Ctable_name+FROM+information_schema.tables+WHERE+2%3E1--%2F%2A%2A%2F%3B+EXEC+xp_cmdshell%28%27cat+..%2F..%2F..%2Fetc%2Fpasswd%27%29%23

Hi Nicolai,

I haven't been able to meet with both customers to see what they are getting. Cloudflare is a possibility, but we'll have to see.

Clearly what you highlighted is not coming from within their organization (a clear SQL Injection and XSS attempt). I guess I wondered if there could be something in DW that once if finds a banned IP of type IPv6, the code acts up and does not validate them accurately (since our customers stop getting banned once we completetly delete everything in _BannedIps.txt despite not seeing their IP there - at least that's been how our Support Desk people reported it on both occasions). I'll get to the bottom of the mistery :) 

Thank you for your insights,

Nuno Aguiar

Hi Nicolai,

At least we figured why IP v6 are getting logged badly (it's coming up more and more)

If this could be changed, would at least help support them in future versions.

I found a few way to go about it. Here's a suggestion without a lot of refactoring

                    if (IPAddress.TryParse(array[i], out address))
                    {
                        string ipString = array[i];
                        if (ipString.Contains(":") && address == System.Net.Sockets.AddressFamily.InterNetwork)
                        {
                            ipString = ipString.Split(':')[0];
                        }
                        if (!IsPrivateIpAddress(ipString) && !publicForwardingIps.Contains(ipString))
                        {
                            publicForwardingIps.Add(ipString);
                        }
                    }

Best Regards,

Nuno Aguiar

I suggest this:

public static string? GetClientIpAddress(this IRequest request)
{
    try
    {
        // Attempt to parse.
        if (IPAddress.TryParse(request.UserHostAddress, out var iPAddress))
            return iPAddress.ToString();

        return null;
    }
    catch
    {
        return null;
    }
}

Looking at headers like this is a security breach anyways...

Hi Nicolai,

Sure, I'm happy either way. Can this change be made to:

• DW9 - /src/88 - Content/Dynamicweb/SystemTools/Security/IpBanner.cs
• DW10 - /src/Features/Content/Dynamicweb/SystemTools/Security/IpBanner.cs

Registered as a feature change - devops#23002 - pull already made for DW10

Hi guys,

What was the culprit in your case Nuno? We are running into similar problems since about ten days and are still looking for a solution.

Kind regards,

Anouk

Hi Anouk,

Do you use a WAF much like Cloudflare? Our issue is that Cloudflare would move the client's IP to a new header (CF-Connecting-IP) and, most importantly, added it's own IP to the X-Forwarded-For.

The problem was that DW was using the X-Forwarded-For header's first IP it finds, which is what we were getting in Banned IPs. We assumed CloudFlare does a good job keeping those mappings (i.e. my real ip would always get the same CF IP), but I could never find that mapping anywhere, so I was stuck.

We tried to implement this https://developers.cloudflare.com/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips/ without success

I know the IPBanner code has changed now, but I haven't tested it yet. I know it's not looking at specific headers anymore.

Our issues were also related to IPv6 (some devices only communicated with IPv6), that were not being properly logged. It considered only the first group (4 digits), so it was likely that thousands of IPs would be considered banned as well. This has also been fixed in recent versions.

What we did was to mimic (as much as possible) the regex's from DW as WAF rules in CloudFlare. That way, CF only blocks the requests (and never reaches DW). That reduced our issues, because what we were having were infected computers (or bots, or malicious attempts, or ethical hacking classes) from Universities, which blocked their IPs, and other departments were trying to purchase on the site and were Banned.

Hope this helps.

Best Regards,

Nuno Aguiar

We changed DW9 so it will not read from the header directly as that can go wrong - so now there is an explicit setting for which header to read from if any.

In Dynamicweb 10.13 we have implemented ForwardedHeadersMiddleware  https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.httpoverrides.forwardedheadersmiddleware?view=aspnetcore-9.0

Hi Nicolai,

I don't see any change in DW9 (looking at the History of IpBanner.cs for DW9). I also checked active PRs for DW9 that could suggest it.

Are you sure someone changed it for DW9? Or you meant DW10?

Best Regards,

Nuno Aguiar