remove phpinfo from core for security reasons: PCI-DSS

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
greggles's picture
Posted by greggles on February 3, 2010 at 4:14am

A site that I'm working on has gone through a PCI scan and the reviewers said that the call to phpinfo disqualifies the site from passing the PCI certification.

Ever since Drupal 5 a call to phpinfo() has been included in system.module.

So, what is the solution if your PCI reviewer sees this as a problem? Do we just patch it to remove the call to phpinfo and replace it with a suitable message? Should we push back on them and say that nobody else is requiring this?

Comments

related topic: Ubercart friendly PCI certifiers

Posted by greggles on February 3, 2010 at 3:23pm
greggles's picture

Are there any PCI certifiers who are Ubercart/Drupal friendly?

I don't necessarily want someone who will give a low quality review just so that they pass but it seems useful to have a couple of known companies who provide high quality reviews and are familiar with Drupal/Ubercart.

knaddison blog | Morris Animal Foundation

Suggestion

Posted by rjbrown99 on March 11, 2010 at 7:33am
rjbrown99's picture

I have used Accuvant for many services, including PCI, and they have some very sharp people on staff. Not sure of their level of knowledge with Drupal but in general they are definitely smart enough to provide advice on certification and what can and can't be included.

The phpinfo() call is not open to the world, right? It requires an admin to be logged in. I can't see why any PCI reviewer would call that out if it required admin rights to hit the phpinfo() call. What specific control number of PCI are they talking about? There's nothing that says "don't allow phpinfo" in the standard.

More info on the reason of disqualification

Posted by VinceW on March 11, 2010 at 9:28pm
VinceW's picture

Hello Greg,

Did the auditor/reviewer gave any specific reasons why the call disqualifies the site. My experience with reviewers is they mostly:

  • point out an issue,
  • give you a reason / opinion / link why -they- think it's an issue
  • give you a solution to resolve the issue

So I'm curious the the reason why this issue only disqualifies the site. My guess is to much information leakage. (see: http://www.owasp.org/index.php/Top_10_2007-Information_Leakage_and_Impro... )

A small piece from this page:

Verifying Security
The goal is to verify that the application does not leak information via error messages or other means. Automated approaches: Vulnerability scanning tools will usually cause error messages to be generated. Static analysis tools can search for the use of APIs that leak information, but will not be able to verify the meaning of those messages. Manual approaches: A code review can search for improper error handling and other patterns that leak information, but it is time-consuming. Testing will also generate error messages, but knowing what error paths were covered is a challenge.

In my experience most of the time after an audit/review, there was a management discussion (builder/auditor/client) about the outcome, the findings, severity and a follow up (or not).

So, what is the solution if your PCI reviewer sees this as a problem? Do we just patch it to remove the call to phpinfo and replace it with a suitable message?

I think we should be able to build a system (drupal) where a system-maintainer is able to switch some issues on/of depending on the level of security wanted/needed. A bit like the famous 'Use PHP input for field settings ' option on the admin/user/permissions page.

Should we push back on them and say that nobody else is requiring this?

IMO this is not a one-on-one question/answer. It's also depending on the system your building, the context it's in, the level of compliancy required, the further findings of the review, the risk this (and/or other) finding(s) is bringing to the system, the level of acceptance of this risk by the organisation, etc.... So the answer to your question isn't always obvious but depending on various issues.

Looking forward to your reply,

Best,
VinceW

-=[ Your Information Matters ]=-

limited interaction

Posted by greggles on March 12, 2010 at 2:33pm
greggles's picture

Sadly we had limited interaction with the auditor and were contacted after the report was done and contact was over. So, I can' answer many of your questions (nor rjbrown's).

I agree that they probably felt this was information leakage, though it's hard to understand since the phpinfo is protected by an admin permission.

I think you are somewhat right that the phpinfo should be something that can be disabled, but to pass a review like this...where/how should it be disabled? If we can disable it like a module then an admin could just enable it. If we disable it in settings.php or something it becomes much less valuable as a debugging tool.

I think the solution here should have been to just argue with the reviewer that phpinfo is harmless in this scenario because it is protected by the Drupal permission system. Sadly we weren't in a position to do that.

knaddison blog | Morris Animal Foundation

It's absurd they would take

Posted by rjbrown99 on March 17, 2010 at 5:14am
rjbrown99's picture

It's absurd they would take issue with a phpinfo() call that is protected by admin rights. If you have admin rights, you can just create yourself a php block and drop in a phpinfo(). This is just a misunderstanding of PHP and Drupal by the firm creating the report.

Was this a pre-certification health check or an actual QSA-certified auditor during a real PCI exam?

I totally agree with the argue-it approach. Admin rights inherently are ADMINISTRATIVE in nature. An admin runs the site and has permission to create/edit code. They have phpinfo and everything else and it shouldn't change your PCI standing unless it was available to an unauthenticated user.

The only thing I can think is maybe it was available to non-admins as well...?