CF 7 PCI compliance issue

It seems the issue was one of the IIS sites on the server did not have a host header bound to it's SSL port.  Now that the site is bound to a specific host header, IIS has no "default" SSL site to fall through to, so it returns the expected "400 Bad Request (Invalid Hostname)" error when the GET / HTTP/1.0 without a Host: parameter comes in.

FYI, the command to create the SSL binding is of the form:

cscript.exe c:\inetpub\adminscripts\adsutil.vbs set /w3svc/123456/SecureBindings ":443:mysslsite.mydomain.com"

My solution has been to re-write all the CF functions in .NET and remove CF from the server.

Here is a link to the security document that Steve references.  Note, it is for CF9.

http://www.adobe.com/products/coldfusion/whitepapers/pdf/91025512_cf9_lockdownguide_wp_ue.pdf

We are running into this exact same issue with CF9.

We did this on our Windows 2003 server

http://support.microsoft.com/kb/834141

and when I ran the PCI scan it still came up with the private IP in the HTTP headers. So I kept searching for a solution and found this.

http://blogs.msdn.com/asiatech/archive/2009/03/13/why-private-ip-addre  ss-is-still-leaked-on-iis-server-even-after-applying-fix-834141.aspx

So it looks like CF is intercepting the HTTP GET command and displaying the HTTP header with the private IP address.

We can't delete the "wildcard ISAPI DLL" from IIS6 because CF will stop working. Did anyone ever come up with a solution to this huge problem? Thanks.

1. The article you link already has the answer:

We can either ensure the HTTP client application includes a HTTP:Host header value in its request. (Actually HTTP:Host headers are required by the HTTP/1.1 specifications (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23) or write an ISAPI filter that blocks and rejects any incoming HTTP requests that do not include an HTTP:Host header.

So configure a Host header in your IIS website.

2. I fail to see where the PCI specifiction says said behaviour is non-compliant.

I have run across this exact same issue as bscenefilms

Assuming for the moment that there is no fix to that wildcard DLL, does anyone know how to create an "ISAPI filter that blocks and rejects any incoming HTTP requests that do not include an HTTP:Host header".

That appears to be the only work around I have come across after hours of tracking this down.

PCI is a standard that was created by the industry, and it shows clearly that the people who helped to devise it were not extraordinarily technical people.  They identified a laundry-list of "every possible vulnerability they could think of," but there really isn't a sense of what is more crucial or less.  There also is no sense of a management strategy.

In contrast, I would recommend that you should spend some time studying, of all things, the HIPAA Act, which of course concerns healthcare.  My point is that this was an extremely well-reasoned piece of legislation in most respects, and the available material does talk quite extensively about the fact that security is an ongoing process as well as a thing that must now-and-forever be properly managed.

I don't know whether the retailer in question, in the recent mass-theft, was "PCI compliant" or not.  They may well could have been!  Yet they obviously were not secure.  Or maybe a better way to put it is, "whether or not they were 'secure,' the sensitive data nevertheless was successfully misappropriated in a felonious way."

"Your job isn't to mind or mend the fences.  Your job is to make sure that the horse-thieves don't get in and out with my prize race-horse."  To achieve that, you can't be staring mindlessly at fences all day.  You have to regard the entire farm, and you have to have a very comprehensive and manageable plan which can be second-nature even to the stable-boy who's not getting paid much more than minimum wage.  That guy with a magnifying glass is gonna find a defect in every single fence, but... the horse is still there, and the horse-thieves are not.

Let's be realistic:  there is no "silver bullet."  It ain't Cold Fusion, and it ain't dot-Net.

If the issue of PCI Compliance is that "an internal IP-address is being leaked," first make sure that your software is up-to-date (i.e. convert to the latest ColdFusion and Windows versions and service-packs), then make sure that, even if an internal IP address is leaked, it cannot be accessed from the outside.  (I have never quite understood some of the "requirements," including this one. IP addresses can always be 'port-scanned' if you can get to the subnet, and they're quite useless if you can't.)

Nevertheless, whether or not you agree with Adobe or ColdFusion, "it's what you got," and any substantial conversion of any tool to another platform is always tantamount to "starting over from scratch."  You're just not gonna get that through the bean-counters (if they are any good at all at bean counting).  You've got millions of dollars invested in whatever you've got.  Scrapping it all, in pursuit of closing some very-tiny "hole" that it might not be possible for any real-world intruder to pass through, is just not gonna happen.

There are very fundamental reasons for "what all the fuss is about" vis-a-vis ColdFusion:  the total cost of ownership is much less than with other tools including dot-Net because of its declarative syntax and efficient, just-in-time implementation.  Maintaining a "web site" with most tools is actually a task of maintaining hundreds of hand-crafted computer programs, whereas ColdFusion uses a clever and transparent code-generator to give you the same "bang" for a lot less "buck."

This seems like an IIS issue.

Out of curiousity, how does PCI compliance relate to this issue?