Escaping PHP input -- not normal input

[linus72982]

I am writing a script that will parse my PHP classes and check for things like coupling, visualize my objects and connections, dependencies, check for convention usage, etc.

 

So, I have a simple file upload.  I'm never saving the files, just get contents and dump the file and work with the string version.

 

I'm writing it for me, but I figure I might want to open it for others to use in the future, so I may as well write it that way to begin with -- so I need to validate user input.  Problem is, the user input is supposed to be valid PHP code.  I'm thinking that, as long as I'm careful, I shouldn't be executing any code contained in strings, but I'm no security expert and I want a warm fuzzy that my thought on this is correct.  What kinds of things do I need to look out for?  Is it possible to inject when working with strings?

 

My initial thought is to regex the entire file and replace key portions with known replacements.  So ( and ) would become !* and !^ or $ would become @~ (combinations that -- I think -- don't make sense to php?)  But that may be completely unnecessary processing time if I'm not in any danger, here.  Thanks ahead of time for any help.

 

PS - as a side question -- what's the best way to verify a file is a php file?  I know of getimagesize for images, but should I just check for <? to verify it's php?  That seems like it would be too easy to fool -- then again, it might not matter much.

 

-Adam

[requinix]

It is possible to execute code safely, but it's difficult and I wouldn't even trust myself to get it right.

 

However all you need is a syntax check, right? PHP can do that from the command line.

"php -l " . escapeshellarg($_FILES["whatever"]["tmp_name"])

I believe it uses exit codes for success and failure so you can use exec() or proc functions to check that.

 

Any file is a valid PHP file so that's difficult. But with your specific use case there would have to be some amount of PHP code, right? So yes you can check for <?php.

[Jacques1]

Hi,

 

messing with the code or validating it in an attempt to make it “secure” (whatever that means) is nonsensical.

 

Content iself is not “dangerous”. This is a common misconception. If an application is vulnerable to, say, SQL injections, that's not a problem of people writing down SQL queries. The problem is that the server misinterprets data as executable code. That's what needs to be fixed.

 

So your job is to make sure that the PHP code is always treated as text and never executed. Storing it in the database is fine, putting it into a file not so much. Running it through the PHP interpreter as suggested by requinix is also something I definitely wouldn't do. And of course you must keep away the code from any evaluation function like eval(), create_function(), preg_replace() with the “e” modifier etc.

 

What do you mean by “verifying that it's a PHP file”? Technically speaking, any content can be considered a PHP script, because there's no rule saying that there must actually be a PHP section. For example, the whole script may consist of plain HTML.

 

In your case, it probably makes sense to treat the entire content as one big PHP section, optionally delimited by explicit PHP tags. So the content either starts with a “<?php” or “<?” tag, or there must be no starting tag at all (in which case the entire content is regarded as PHP code). Then you run the code through an external(!) PHP parser to make sure it's syntactically valid. Note that this has nothing to do with security. It simply prevents users from accidentally uploading garbage data.

Edited May 20, 2014 by Jacques1