Hacker News Reader

Comment by Joakal | Hacker News Reader

It's needed to connect to databases with authentication. What would you suggest?

I believe the way to do it "correctly" would be to put the actual file containing the credentials in a non-public location and just do an include where you need to access it. At least that's how I do it. I could be wrong...

If one would made a similar typo in that file, its contents will be displayed too.

A solution would be to have a .ini-like (or some other simple-to-parse format) config file and PHP code to read its contents. PHP code could be leaked, but config file contents wouldn't.

Yeah seen a few client libraries that are doing that. Even putting them in a config only file lessens the chance of something like this happening as it is modified a lot less often.

Deleted comment

I believe you are wrong. include()/require() would equally happily display any file's contents outside of `<?php ... ?>` scope (the case with "i?php"), within document root or not.

Edit: I've tested this:

    $ php -v
    PHP 5.2.6-3ubuntu4.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Sep 16 2010 19:51:25) 
    Copyright (c) 1997-2008 The PHP Group
    Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

    $ cat test.php
    <?php
        require "/tmp/test2.php";
    ?>
    $ cat /tmp/test2.php
    i?php
        define("TEST", "test");
    ?>
    $ GET http://localhost/test.php
    i?php
        define("TEST", "test");
    ?>

Off course, but in this case, passwords would only be exposed if the config file had a miss-typed opening PHP tag. If "test.php" had it, you wouldn't be able to see the contents of "test2.php".

Yes, you are right. And in this exact case they (mis-)edited the file, that contained passwords (i.e. test2.php in my improvised example).

Sure, I was replying for this hypothetical situation that you guys ware discussing, where they would store passwords in a different file outside of webroot ...

it's always included to the document root (the bootstrap file). it doesn't matter where you're including from, a broken open tag would cause errors like this one.

If you're doing an include, wouldn't the passwords still be in a PHP file?

if the php file is printed rather than executed, the include will not be followed. You'd see the "include /path/to/inaccessible/file" but you wouldn't see the passwords within the include.

I think. I haven't seriously used php since 2003 or so.

Yes, but included files still need a <?php tag at the top, or PHP just prints them out.

That wouldn't help in this case, since a typo in the config file is making the file not be parsed as PHP.

If you want to avoid that possibility, you can use a non-PHP format (eg: YAML) and parse it.

Client SSL certificates? I don't know what DB they're using, but at least Postgres and MySQL support certificate-based auth.

How is a client certificate different from a long random password? Both have to be stored somewhere. The correct solution is to keep this (and everything else) out of your web root.

If that i?php blunder happened to me, my users would see 10 lines of code. One include for the framework (which lives outside the web root), plus three calls to get the framework to handle the current request.

Those 10 lines would be totally unproblematic

.pem file won't be leaked in this ("i?php") manner. Only file's location would be revealed.

Of course, you are completely right, it should still be inaccessible from the web.

Typically, these files are not web accessible. Problem solved.

This bug was nothing to do with the file being web accessible. If you miss the opening <?php tag out in any file, regardless of whether it's in the web root, it will get printed straight out to the browser.

But you would never `include()` a PEM file.

Reply on news.ycombinator.com