Should Mozilla cache files ever contain PHP eval statements?

Solution 1:

New answer

You said in the comments that you actually don't know whether this is a PHP eval() in the first place. The thing is, PHP is not the only language that has an eval() – JavaScript has an eval() function as well.

Now while having PHP code in your browser's cache is mildly unusual, having JavaScript code in your browser's cache is completely normal, and yes that even includes code which calls eval().

(For example, a website could use JavaScript to dynamically refresh some data (such as the "installed packages" table), by receiving updates in JSON. While modern JavaScript has a dedicated JSON-parsing function, for a long time it did not – instead, to parse a JSON string you would eval() it.)

This does not mean the code was generated by a process on your computer. It was received by the browser, but that's how all websites work, and it's pretty much the purpose of a browser's cache.

I'm not a programmer, but it sure looks like obfuscated code to me

If a website uses obfuscated code, that's really their business.

But nowadays, many websites use obfuscators called minifiers, where the goal is simply to compress the JavaScript code as much as possible (e.g. shortening all variables to 1- or 2-letter) so that it could be downloaded faster by visitors, with obfuscation as a secondary effect. You will see this on just about every larger website you visit.

(Some obfuscators and minifiers indeed use eval() to reconstruct parts of the original code.)

Original answer

If you open a webpage that literally contains an unprocessed PHP statement, then yes, it'll of course show up on the network and in the page that you see, and therefore also in the cache.

For example, if I type this in the answer form:

<?php eval("echo 'Hello!';") ?>

now your cache for superuser.com has a PHP eval statement in it.

However, your browser doesn't process PHP statements; it either treats them as regular text or as a weird nonstandard XML processing directive. If they were supposed to be interpreted, that'd have happened on the server – you wouldn't be supposed to receive them.

The real question is whether the website should have had that statement in the page you visited. It could very well might be something that was added maliciously, it might have been added to a completely wrong file, or it might be just ordinary text in that page.

For example, if an attacker uploads a PHP script to a site that doesn't use PHP, then it will not be interpreted – you'll get the source code as text. (Some attacks involve putting PHP code in e.g. the GIF or JPEG comment field, uploading it as a .gif and tricking the server into interpreting it as PHP.)

But as another example, if the website has been unmaintained for years and uses legacy <? short open tags, modern PHP won't look at those anymore and you'll see the raw PHP statements in your browser instead. This isn't anything malicious, just a sign of the site being incompatible with the webserver.

Answer to comments

even just boot my dedicated machine for OPNsense, all five try to send data to a whole range of IP addresses that include websites I have never visited (I did whois and reverse ip on most of the offenders), DOD, Army, NASA, GROOT, BROOT, RIPE Coordination, APNIC, Amazon dogfish routing, and on and on. These ips never show up in the workstation fw logs, only on OPN.

All of those sound completely normal when put together.

Your OPNsense system is running Unbound as a DNS resolver. It doesn't just forward the requests to another server – it acts like a full resolver (like the ones run by ISPs), chasing DNS delegations from the root down to the TLDs and the actual domains, by itself.

First, this means that each DNS request (made either by your workstations or by OPNsense internal processes) will result in more than one DNS query, as the resolver doesn't immediately know where to ask the final question, it has to find out by following delegations.

This process always starts at the DNS root, and many of the organizations in your list are simply hosting instances of the nameservers for the root zone – it is normal for a DNS resolver to be probing them on startup. Yes, DoD indeed hosts one, and so does the US Army, and so does RIPE, and NASA. (And e.g. "GROOT" is a dedicated address range for the 'G' nameserver.) You can see the full list at http://root-servers.org.

The same then applies for the nameservers of the TLD, and then of the actual domain being resolved. Often, even the domain's nameservers will seemingly have nothing to do with the domain. For example, Amazon (known for AWS cloud computing) provides the "Route53" DNS hosting service that many websites use.

So whenever OPNsense starts up and contacts opnsense.org to check for available updates, the DNS resolver has to contact that domain's authoritative DNS servers (e.g. ns3.openprovider.eu) – which indeed are hosted at Amazon. (I'm not sure whether openprovider uses Route53 or Cloudfront or EC2, but it's all the same AWS in the end.)

It is never enough to look at only the IP addresses: you have to look at the actual traffic that's being sent to those addresses (or received). As the bare minimum, look also at the protocols and ports – I'm fairly sure these are UDP packets to dstport 53, i.e. DNS queries.