The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Like every sysadmin I am concerned about php shell attacks - I have many layers of security in place for mail and web but it occurred to me that there is an incredibly simple way to thwart almost all php injection - but it requires a modification to the PHP library.

The concept? "validation tokens".

A token can be placed in the PHP.INI file, http.conf container or htaccess, can be in one or all of those places and might look like this:

validation_token=AABBCCDDEEFF

Without this token at the head of a PHP script, the script would not run. Again an example might be:

<?
#token:AABBCCDDEEFF

If this were in place you could choose to secure any or all servers, files, directories etc against "foreign" scripts.

Would this be a PITA to switch to - probably
Would it cause some problems along the way - almost certainly
Would it prevent anyone but authorized users from executing PHP scripts and provide an almost infinite layer of protection for all servers / clients / folders / files... I think so.

Please feel free to shoot holes in this idea - if it stands up to a bit of scrutiny I'd love to suggest it as a feature to the PHP team - or maybe someone can come up with a patch or mod.

Normally this would be a big security hole if the $_GET value isn't checked...someone could easily include a remote script.

Unless I misunderstand your idea I don't think the token would solve anything (if remote includes are still enabled). The local script has provided a valid token, and now the dangerous, remote code is just getting executed in the global scope.

include et al are pretty much like copying and pasting the code directly.

cranial-bore, I think clickbuild meant that all scripts (so the ones which aren't requested directly, but included as well) should have the token

Idea is nice, but it's not very practical: would you edit all script files to contain the required token? Sure, this could be automated to some extent, like to auto-add token for all local scripts on the server level, but remote would still have to be edited manually.

I still think that the best way to protect from "PHP injection" is to make sure that you include the right thing