It's also worth noting that a server not running PHP could, for any or no reason, intentionally do any of the things that would otherwise indicate a PHP installation serving the pages you are viewing.

It's worth noting that the last PHP version that had the easter egg was 5.4, which is EOL since 2015.

“On a properly configured server, it is not possible to know for sure if PHP is used or not.” That’s a dangerous assumption there.

Could also add that the overwhelming majority of php sites are based on one of not-that-many frameworks or cms, which in very many cases can be deduced from the delivered html/css. Example: nearly all wordpress installation use some wordpress-specific skin, so if you see that, it's nearly guaranteed that the server is running php.

Similarly, CMSs require an admin site, many of which use a prefigured url route e.g. mysite.com/admin. It wouldn't be hard to try all common possibilities until you hit the admin site's login page. Again, easy to mitigate against, although it is one extra possibility to look for.

@КонстантинВан that's not dangerous because it is not a declarative absolute. The statement says that one cannot be sure either way. There is only evidence to support a hypothesis but that evidence could be misleading.

A method that is guaranteed to work: Just try a recent PHP exploit. If it works, the site is using PHP.

@fraxinus What if there is no recent universal, unpatched PHP exploit?

@schroeder that statement is a declarative absolute. it is not possible to know for sure → the "it is not possible" is as absolute a declaration can be. And it is wrong too, for reasonable degrees of certainty. Eg if I see a well-known wordpress theme on a page with a typical wordpress layout, I am ready to bet PHP is used. Yet this does not imply the server is misconfigured, unless you define "run wordpress" as misconfigured.

@КонстантинВан It's not an assumption, it's a tautology: If it reveals itself, it's not properly configured.

@Barmar The internal implementation of the PHP engine is not what you can configure.

@Barmar> the assumption is the belief that everything observable about the presence of php can be configured.

@spectras "I am ready to bet " - so, you're not sure?

I was thinking of "configuration" more generally, including the programming of the PHP implementation. But that's really out of control of the site operator (except for selecting a version).

@schroeder If am sure enough to take a bet 1 to 100. That's more that what an attacker needs to decide to crack your PHP. Now if you want to play it stupid with numbers, then yes you cannot be sure of anything. Perhaps I do not even exist, and pure luck made static noise post that message. It is mathematically possible, so you cannot be sure of the opposite.

I think you're missing the point both I and MechMK1 are making

Well your point as I understand it is you believe everything observable about the presence of PHP can be hidden through configuration. But then I cannot be sure that is what you want to say.

@schroeder I would argue the opposite, that you are both missing the point of the comments. It's not about the definition of "sure", it's about the premise of the statement being wrong. Lack of "proper configuration" is just one possible way that the server could reveal (or not) its status. You can have a "proper configuration" and the attacker can break into your building and inspect your server's hard drive and be "sure" of whether or not it runs PHP (disregarding any philosophical debate about the nature of certainty). Or, less extreme, the attack can take advantage of a bug.

@schroeder And yes, the server could be faking replication of a known bug in order to deceive you into making a conclusion, or they could have planted a fake server with a fake hard drive and left the window ajar for the attacker, but if we resort to these types of arguments then literally nothing is "sure" so any statement about whether it is "possible to know" something becomes useless. At some point one needs to be pragmatic. In the pragmatic sense, assuming that a "proper configuration" takes care of everything gives a false sense of security.

@spectras nope, that's not my point. You've missed it.

@JonBentley I see no reason to engage with ad reductio ad absurdum arguments.

@schroeder It's not ad reductio ad absurdum. Attackers using physical access and/or taking advantage of bugs is a real phenomenon which happens frequently in the real world and should not be dismissed.

@schroeder Also on a separate note, I was polite and constructive in my comment. You have been rude and dismissive in both of your latest comments. As a moderator, I would hope you would hold yourself to a slightly higher standard.

@JBentley you are reading in tone. And physical attacks are not in scope, so to reduce the discussion to "if we resort to these types of arguments then literally nothing is "sure" so any statement about whether it is "possible to know" something becomes useless" is the textbook definition of ad reductio ad absurdum.

Firstly, they are in scope because the question asks "How can an attacker...?" and this being security stack exchange, it is unreasonable to suppose that we would arbitrarily exclude a class of attack. But secondly, even if we suppose you are correct, that was just one of two examples I gave - the other being a non-physical attack. I assume that you are not also considering software vulnerabilities to be out of scope.

But more importantly, to bring this back to what the debate was about. Your first comment was in reply to a comment that said "That's a dangerous assumption there". Your response was "that's not dangerous because it is not a declarative absolute".

Respectfully, that was the moment the point was missed. The assertion that it is dangerous wasn't about nitpicking the semantics, it was pointing out that it is dangerous to assume that if all you do is a "proper configuration", then it will be impossible for someone to obtain the data.

@schroeder

Yes, if we want to be absolutely technical and interpret the words with their precise meaning, then if all you do is a proper configuration, it will be impossible to know for sure. But equally, it would be impossible to know for sure even if you didn't do a proper configuration, so again we're back to a statement that is not very useful.

Did you see the PHP install that was configured to run PHP from .asp files?