phpinfo() doesn't play nicely with strict CSPs

[Synchro]

Description

The output generated by phpinfo() includes inline styles and data: URLs for two images. While this is self-contained, it's incompatible with Content-Security-Policy headers that are configured securely, specifically, if your CSP doesn't include 'unsafe-inline' for style-src and data: for img-src, the output looks bad:

Two of the 6 locations in the output (i.e. not many) that uses inline styles:

                  <tr>
                    <td class="e">highlight.comment</td>
                    <td class="v">
                        <span style="color: #FF8000">#FF8000</span>
                    </td>
                    <td class="v">
                        <span style="color: #FF8000">#FF8000</span>
                    </td>
                </tr>

styling like this would need to be turned into classes, though as you can see this output already makes use of classes, so this is trivial to fix.

A good way to resolve this would be to extend phpinfo so that it can serve these resources separately depending on the request context, so for example a request that contains a request param like phpinfo=styles could serve the style sheet, and phpinfo=logo could serve a logo image.

This approach would be compatible with a super-strict CSP like this (in fact there's nothing preventing phpinfo from generating this header itself):

Content-Security-Policy: default-src 'none'; image-src 'self'; style-src 'self';

The downside of this approach is that it would end up making multiple requests to serve the same page content. I don't know if there is a way that the existing approach could be preserved while allowing for this more secure approach as well.

An alternative would be for the page to generate CSP nonces or SRI hashes for the data and style elements. That's probably more complicated, though it would allow the page to remain self-contained.

Since phpinfo is a development feature, it's not very important to fix this, but it's an easy opportunity to encourage secure development practices while also making the generated page immune to injections.

[heiglandreas]

Why would you want to display the PHPInfo data publicly where you do not have control over the Server providing that data?

And when you have control over the webserver providing that data, can'T you set the CSP accordingly when someone requests the PHP-Info page?

For nginx for example something like

location /info {
  add_header Content-Security-Policy "default-src 'self';";
}

[Synchro]

I don't want it public, but I think dev envs should be secure too. There are workarounds, but it would be nice to avoid the need to accommodate its shortcomings, make it secure by default.

More generally, I think CSP should be set by apps rather than server config so that the config travels with the app, since they tend to be very app-specific, and also plays much better with bottom-of-the-barrel shared hosting.

[heiglandreas]

The challenge I see is that the PHP-Info page reveals so many issues that CSP is perhaps the least of all...

Improving developer-security by improving CSP on the PHP-Info page seems ... an interesting approach. Especially when something like

    #[Route('/info', name: 'info', host: '%teamup_public_host%', methods: ['GET'])]
    public function infoAction(Request $request, NoPrivateNetworkHttpClient $httpClient): Response
    {
        header("Content-Security-Policy: default-src 'self';script-src 'unsafe-inline'; style-src 'unsafe-inline'; img-src 'self' data:");
        phpinfo();
        exit;
    }

allows one to see the PHPInfo outputwhile setting the CSP explicitly on the app-level for that info-screen.

[Synchro]

Yes, I know you can work around it like that, but it's a user-side string and duct-tape solution that involves deliberately lowering security rather than avoiding the cause of the problem. I'd prefer to not have to think about it and have it "just work".

I've been dabbling with a patch to fix inline styling as a start.

[staabm]

I've been dabbling with a patch to fix inline styling as a start.

agree, that this sounds like a good first step. maybe you can even use css-variables and make it easier to maintain colors

[Synchro]

Injecting the highlight colours into the CSS is easy enough, but changing the HTML output (which is what's generating the inline style attrs) is using the zend_highlight function to make the span tags. It can't be fixed in there, because that function is used outside phpinfo where it doesn't have the benefit of a stylesheet. I guess the workaround would be to not use zend_highlight in phpinfo – presenting those ini values is the only thing it's used for.