possible to include a file but not view it?

sfullman

Hi There,

I'm setting up a large company and would like to keep connection usernames and passwords secret from the devteam. Here's the dilemma I'm facing:

suppose I have my developers put the following at the top of their script:

// includes the file and calls the connect function
include_once("/home/site/restricted/connect.php");
connect();

They can connect to the database yet never know what the username and password are (cause they're stored in the connect() function and are therefore not global).

However, if I user knows the path /home/site/restricted.php, he or she can just as easily do this:

$hahaIgotyou = implode('',file('/home/site/restricted.php'));

echo $hahaIgotyou;

Is there any way around this? I've thought of having PHP call a php executable file and have an object, apache aliases, and haven't thought of a way yet.

I will honestly pay $50.00 to the first person who can give me a solution to this and show me why it works security-wise.

Sincerely,
Sam Fullman
Compass Point Media

Sxooter

easy, either move the files out of the web server's document root path, and add the new directory to php.ini's include path, or use a unique extension (I use .inc) and set apache to deny it.

We do both on my boxes. All include files end in .inc, they get put in a directory outside the web server (/www/server is the root, for example, and /www/php_include is the include directory)

To have apache deny serving .inc files, add this to the httpd.conf file:

<Files ~ "\.inc$">
    Order allow,deny
    Deny from all
</Files>

Arc

actually i belive the only thing they would see is any html or test you may have in the connect file. I just tested it on a page that was pure php and nothing showed up, but when i tested it on a file with html all of the html showed up but not any php.

Where can i send my address to recieve my check?🙂

Sxooter

Arc is correct that if you use an extension set to be handled by PHP, it will get interpreted and the user won't see anything in the file.

However, if you're using an extension like .inc which usually isn't setup to be interpreted by php, then you need to hide them from the user, or they can guess the names and bring them up.

sfullman

Hello again,

I'll send you the $50.00 but I'm going to get my money's worth :-) Are you saying that if I place the file in a wierd directory like:

/home/outside_root/sieivoethfdiowm/connect.php

and then set that path in my php.ini, that the user will just type in:

include_once('connect.php');

and never know the path?

Question #2: What's to stop them from running phpinfo(); and finding out the paths, and recursing until they've got it?

I'd also need like a 5 step direction on doing this, but I'm good for the dough.

Sam Fullman :-)

sfullman

Also,

You said that the file would be interpreted as HTML. I dont' want it interpreted!!! I want it compiled, and want that Resource ID# to be avaiable when the script executes...

Sam

stolzyboy

you won't get it compiled since PHP is not a compiled language, it is an interpreted language like PERL, unlike JAVA.

and when they say it will be interpreted, when you run the php script, your connection strings won't be shown when you view source, cuz the PHP interpreter converts what it needs to HTML, and since nothing is echoed to the browser, they can't see the connnection strings

superwormy

Everythign thats' been said so far is totally off-base.

If the development team can include the page with that code, then they can fread() it, file() in, whatever locally and see exactly what you wrote.

You have pretty much two options here... one, trust your dev team. :-) Two, develop on a DEVELOPMENT server, which uses different passwords and usernames from the real server. You change the usernames and passwords youself when you go online, and upload to the real server yourself.

Everyone who's said anything so far is talking about letting Apache deny thigns, which does NO GOOD AT ALL when your dev team OBVIOUSLY has to have access to the computer itself ( ie NOT OVER HTTP ) cause they are editing and creating files on it to build the app with.

On a side not, its generally better to name everything .inc.php or SOMETHIGN that ends in PHP, because if you don't, you're gonna be fvcked when someone accidentally copies your file to somewhere world-readable, and everyone on the internet views yoru passwords and usernames over HTTP. If it was ending in .php then you're file will just display nothing at all ( assumign its just PHP function calls )

paul088

I don't think implode could do anything to show non-html code in php file. Test it yourself if you are still worried.

sfullman

Superwormy,

Thanks for your input, I wasn't sure it could be done. And no, I don't trust my dev team :-)

Wouldn't there be a way to have a standing executable which could pass senitive information over to PHP? The objective is to have function-like files that can be called, but NOT read.

If there is any other option available in that area, please let me know. Also I don't suppose symbolic links would work because if PHP can follow it to execute it can follow to write, correct?

Sam

superwormy

paul088 REMEMBER, you're not reading over HTTP, we're readinga local file, so YES, YOU WILL be able to view the source.

$var = file ("/home/superwormy/file.txt");

NOT

$var = file ("http://superowrmy.com/../file.txt") or something query like that.

And yes, I tried it. And yes, it worked.

You might be able to make an EXE, but what'll you pass back to PHP? An authorization code or something? What if they change the code that calls the EXE file? I guess I dont' know, can't think of anything at the mome... oh, heres an idea. What about gettinga product like the Zend encoder... can you include encrypted files that got encrypted by the Zend encoder? I don't know... it might be a starting spot though.

stolzyboy

what is the reasoning that you can't show them the username and password, they can do anything they want if you let them use a connection string, they can run any mysql queries with php to circumvent the unknown u/p anyway

superwormy

stolzyboy is really right, if you don't trust them, they shouldn't be programming your app.

Theres nothing to stop them from leaving back-doors open and screwing with things later on either.

paul088

To superwormy, If someone can get to the local machine, what the heck does he need to run any script to see anything? You may be able to read plain text file but I doubt you could see xx.php files.

sfullman

Well guys,

This all started out as a very friendly question about "how can you include a file's resources but not reveal a file's contents?" And I also asked, if it was possible, to explain the security logic behind it.

Please no preaching about the harm a developer can do, at this point I'll take it that nobody can give me a specific strategy, and move on.

The $50.00 offer still stands though.

Sam

stolzyboy

the $50.00 offer will never happen with the question you have brought up, so leave it in your piggy bank for another day, good luck

Sxooter

If MySQL supports IDENT authentication, (or if you were using Postgresql, which DOES) then you could do it this way:

set up apache to run su_exec, i.e. the apache children run under the account of whoever's directory they're running in. Then set the web server to use ident authentication. No need for passwords in the database, since ident will authorize based on who the OS says is calling. oh yeah, it's only semi-secure if the apache and database are on the same box, or in a controlled environment (i.e. letting joe user connect via IDENT from his own workstation, where he knows the root password would get around this.

Then have each developer develop out of a directory "owned" by the proper owner for whichever database they're accessing.

superwormy

paul088 you are totally misunderstanding what he's saying here. PHP can include(), file(), require(), fopen() files in one of two basic ways, over the HTTP protocal ( opening a file that Apache has already parsed and sent out as plain text ) or through the file system. If you are opening a fiel system, it's just as if you were opening a file in your favorite text editor, YOU CAN SEE THE SOURCE. It is not parsed by Apache because you're opening it through the file system, not through an HTTP connection to Apache.

Secondly, here is your answer:
http://zend.com/store/products/zend-encoder.php

According to this page:
http://de.zend.com/support/user_docs/ZendEncoder/html/ZendEncoder_TechFAQ.html

You can actually include() encoded files at run-time transparently. So you could use Zend Encoder to encode your script with connection to the database / username / password in it, and it will be entirely unreadable. Then all your dev guys have to do is include() that encoded file, and ta-da, it works.

You might also look at these, as they seem to imply they do the same thing, but are quite a bit cheaper:
http://www.rssoftlab.com/phpenc.php4

Not sure if these ones have this ability or not, you'd have to call and ask, but most likely these will work as well:
http://www.ioncube.com/encoder
http://www.phpguardian.com/products/phppro.htm
http://encoder4php.pag1.com/

sfullman

Well, if I can make any of those work I'll let you know, please PM me with your email or contact and the check is yours. I know Zend isn't cheap but I think this is worth it. Giving everyone a little bit keeps any one person from becoming threatening and actually engenders respect that the owner cares enough to protect his (and his employees') interests.

Thanks and I'll look at this and get back to you,
Sam Fullman