How to turn off expose php?

This article describes how to enable and disable the expose_php directive in a custom php.ini file.

The information in this article only applies to certain types of hosting accounts. To determine whether or not the information below applies to your account, please see this article.

This article assumes that you have already set up a custom php.ini file on your web site. If you have not already set up a custom php.ini file, please read this article first.

Using the expose_php directive

When the expose_php directive is enabled, PHP includes the following line in the HTTP response header when a PHP page is requested (the exact version number may differ depending on your configuration):

X-Powered-By: PHP/5.3.27

By default, the expose_php directive is enabled. However, you may not want to broadcast the specific PHP version your site is using. Similarly, some third-party applications require the expose_php directive to be disabled.

To disable the expose_php directive, use a text editor to modify your php.ini file as follows:

expose_php = off

With the expose_php directive disabled, PHP will not send the X-Powered-By header. To re-enable the expose_php directive and send the X-Powered-By header, modify your php.ini file as follows:

expose_php = on

To verify the current value of the expose_php directive and other directives, you can use the phpinfo() function. For more information, please see this article.

More Information

• To view a complete list of php.ini directives, please visit http://www.php.net/manual/en/ini.list.php.
• For more information about the expose_php directive, please visit http://docs.php.net/manual/en/ini.core.php#ini.expose-php.

That's correct.

Setting expose_php = Off just prevents the webserver from sending back the X-Powered-By header.

While one could say that potential hackers could look for out of date versions of PHP with security holes to exploit, they could potentially do the same even if the header was turned off. In my opinion, it is a good thing to do, but do not expect it to offer much protection.

In terms of interacting with third party services, they should not have to care about which version of PHP you are using. They should be able to serve content in platform-agnostic formats such as JSON, XML, etc, so that the services can be consumed by any platform and not just PHP.

In anycase, for them to rely on the "consumer's" PHP version is useless, as the header can be easily turned off and perhaps even manipulated by the server administrator.

Therefore, it shouldn't be a problem turning it off.

A reader recently brought to my attention a reported vulnerability on servers running PHP. It’s been known about for eons, but it’s new to me and it involves easter eggs in PHP so I thought it would be fun to share a quick post about what it is and how to prevent leakage of sensitive information about your server. It only takes a moment to disable the easter-egg information, should you decide to do so.

What it is..

Here’s the scoop according to the Open Source Vulnerability DataBase:

PHP contains a flaw that may lead to an unauthorized information disclosure. The issue is triggered when a remote attacker makes certain HTTP requests with crafted arguments, which will disclose PHP version and another sensitive information resulting in a loss of confidentiality.

Couldn’t have said it better myself. Basically if you’re running PHP it may be possible for someone to discover the PHP-version and other sensitive information. Also referred to as a type of “fingerprinting” attack. It’s not “threat level midnight” or anything like that, but certainly worth a few moments to lock it down: another layer of protection to increase the security of your website(s).

How it works..

On servers running PHP, visit any page, remove the trailing slash, and append any of the following query-strings:

?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
?=PHPE9568F35-D428-11d2-A769-00AA001ACF42
?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
?=PHPE9568F34-D428-11d2-A769-00AA001ACF42

If the vulnerability is present, requests made with these query-strings results in a variety of easter eggs and detailed PHP credits (see screenshots). When these easter eggs are visible, it means that expose_php is enabled on the server. And when expose_php is enabled, PHP-generated pages are sent with X-Powered-By response-headers that give PHP/version infos, such as “X-Powered-By: PHP/5.4.7”. Knowing the version number of software makes it easier for bad guys to research and exploit known vulnerabilities. So let’s take a moment to “plug the leak” by disabling expose_php.

Disable expose_php via php.ini

If you have access to (and can edit) your server’s php.ini file, the recommended solution is to set expose_php = Off and be done with it. In addition to preventing access to the PHP easter eggs and credit information, disabling expose_php has the added benefit of preventing PHP from sending version information in X-Powered-By HTTP Headers. So instead of sending the following response for PHP-generated pages (e.g., WordPress):

..we send this:

Note that in addition to PHP sending its info via the X-Powered-By header, Apache is sending its version information as well. We can’t disable Apache directives via PHP, but as discussed in my book, it’s simple to do with the following directives placed in Apache’s main configuration file (httpd.conf):

ServerTokens Prod
ServerSignature Off

This simply uses the ServerTokens directive to disable the version number. The ServerSignature directive disables the version info on server-generated pages, which is an added bonus.

Prevent access via .htaccess

If you don’t have access to php.ini (as is the case for shared-server hosting), we can use a thin slice of .htaccess to deny access to the PHP credits and easter eggs:

RewriteCond %{QUERY_STRING} PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
RewriteRule .* - [F]

Just place that code in your site’s root .htaccess file and you’re good to go (no editing required). How does it work? In the first line we’re matching our regular expression against query-string requests (via RewriteCond). The regex pattern may look complicated, but it’s actually using variations on the same pattern, for example:

“[0-9a-f]{8}” matches any sequence of eight numbers and letters “a” thru “f”.

Here’s a comparison to help visualize the pattern:

String: PHPE9568F34-D428-11d2-A769-00AA001ACF42
Regex: PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
Translated: “escaped equals sign, the sequence “PHP”, any sequence of eight, hyphen, any sequence of four, hyphen, any sequence of four, hyphen, etc.”

The line terminates with a “no-case” [NC] flag, making the pattern-match case-insensitive and increasing its effectiveness. Then in the second line, the RewriteRule simply denies access to any matching requests. The terminating [F] flag instructs the server to send along a 403 “Forbidden” status along with the request.

All together then

Combining our two Apache techniques, we get an equivalent to disabling expose_php. Again, editing php.ini is the best route, but when that’s not possible, these two code snippets will get you there.

1) Add to Apache’s main configuration file (httpd.conf):

# m0n.co/9
ServerTokens Prod
ServerSignature Off

1) Add to Apache httpd.conf or .htaccess:

# m0n.co/9
RewriteCond %{QUERY_STRING} PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
RewriteRule .* - [F]

By combining our two methods we deny access to PHP credits/info and disable broadcasting of the Apache version. That’s effective, but unfortunately there’s no way to prevent expose_php from sending its X-Powered-By headers using .htaccess (afaik).

Note also that Apache’s mod_rewrite must be enabled on the server for this to work. If it’s not, remove the second two lines (the rewrite directives) and just use the first two. They’re part of the Apache core and should work to disable the Apache infos.

PHP easter eggs

When something is intentionally hidden within a book, app, or whatever, it’s referred to as an “easter egg”. PHP has at least four of them:

Type	Image	URI
PHP Credits		[server with expose_php = on] ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 Click here for larger view
PHP Logo		[server with expose_php = on] ?=PHPE9568F34-D428-11d2-A769-00AA001ACF42
Zend Logo		[server with expose_php = on] ?=PHPE9568F35-D428-11d2-A769-00AA001ACF42
PHP Logo		[server with expose_php = on] ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42

So what’s the deal?

This is all fine and interesting, but is it worth it? It’s been reported that cPanel requires the PHP version info, so some hosts may leave expose_php enabled for that reason, but isn’t there a better way of communicating sensitive data?

Shouts out

Thank you to Warner Nanninga for bringing this to my attention and helping with further information. Cheers!

About the Author

Jeff Starr = Fullstack Developer. Book Author. Teacher. Human Being.

How to turn off expose_ PHP?

Should I turn off expose_php?

How do I hide PHP version in WordPress?

Where is PHP INI located?