PCI Compliance problems: Same site scripting - due to "localhost.plus.com"

[#1]

We've had to run "PCI compliance" scans for a number of years, to support taking credit card payments.  We're using Plusnet as the business broadband ISP and have a setup which is working well.  These scans have not been an issue for us, until recently.  I'm posting this here - to see if anyone else has encountered the same failure (also - as suggested by PN support).    

The PCI scan report states that the issue is:

>url: http://USERNAME.plus.com/
>matched: Same site scripting detected
>Host: localhost.plus.com IP: 127.0.0.1

This failure is raised when we scanned any other Plusnet internet connection IP address (e.g. those ending in *.plus.com).

Here's what the PCI report says:

Threat:
Most of the DNS servers include records of the form localhost. IN A 127.0.0.1 But if by mistake, the administrator misses the trailing dot, the record is not fully qualified. So if the domain is example.com, the queries for localhost.example.com would resolve to 127.0.0.1. Reference: https://seclists.org/bugtraq/2008/Jan/270
Impact:
The websites in affected domain cannot be securely accessed on multi-user system. The attacker can trick another user on the same system to access websites on affected domain in such a manner as to result in cross site scripting leaking cookies.

Impact:

The websites in affected domain cannot be securely accessed on multi-user system. The attacker can trick another user on the same system to access websites on affected domain in such a manner as to result in cross site scripting leaking cookies.

Solution:
Non fully qualified localhost entries should not be present in the nameserver for domains that host websites with HTTP state management (cookies).

Here's our DNS checks (using Google DNS) - we get the same with any DNS provider:  Plusnet resolves - but many other providers (e.g. bt.com) don't.

nslookup
> server 8.8.8.8
Default Server: dns.google
Address: 8.8.8.8

> localhost.plus.com
Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name: localhost.plus.com
Address: 127.0.0.1

> localhost.bt.com
Server: dns.google
Address: 8.8.8.8

So - this isn't some "local" configuration issue and I've run out of ideas for how to resolve this.  As per the guidence - it seems there needs to be a change to make "plus.com" DNS entries behave correctly.   Other major ISP's DNS do not resolve "localhost.isp.com", so why does PN ?

I've had a Plusnet support case open for months - and been told today that "We don't know how to fix that".  When I asked if they could escolate it within the company we were told "I don't know who to escolate it to".  I was finally met with "We aren't responsible for PCI compliance, so we're not going to do anything".  The support case handler - also said "We have't had any other reports of this - so we're not going to address it".

So - I'm at a loss as to how to resolve this; with  no other answer, we'll have to move ISP.  Also - a little dissapointed in the least with the disregard given to potentional security issues in the PN platform.

Anyone have any other ideas / observed the same sort if issue ?

[#2]

---

@kquigley wrote:

I was finally met with "We aren't responsible for PCI compliance, so we're not going to do anything".

---

If an ISP can't provide a PCI compliant connection then they can't really claim to be a business ISP.

We take credit card payments, but we use Zettle (part of PayPal) who use a secure VPN system that means the connection is secure regardless of ISP (it actually connects via an Android or iOS0 app so works over WiFi or 4G). Other similar card processing companies are available.

Alternatively, there are business oriented ISPs that do provide PCI compliant connections (we no longer use Plusnet so we've solved the problem both ways).

[#3]

Some of these PCI scanning companies seem to be an ever evolving target. I know that's somewhat nature of the beast, however it doesn't explain why I've see scans fail in the past and then miraculously pass on subsequent attempts, despite targeting the exact same customer setup.

Anyway, I digress. I can think of no useful reason why we're doing this, so I've logged it for somebody better versed than me to take a look (for my own benefit - ref: IS-3843).