3 ms·

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

• eam 16y ago
  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...
  • windsurfer 16y ago
    If you're doing an include, wouldn't the passwords still be in a PHP file?
    • lsc 16y ago
      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.
      • russss 16y ago
        Yes, but included files still need a <?php tag at the top, or PHP just prints them out.
  • nbpoole 16y ago
    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.
  • drdaeman 16y ago
    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.
    • deleted 16y ago
      [deleted]
      • sewerhorse 16y ago
        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.
      • drdaeman 16y ago
        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"); ?>
        • CWIZO 16y ago
          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".
          • drdaeman 16y ago
            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).
            • CWIZO 16y ago
              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 ...
• petervandijck 16y ago
  Typically, these files are not web accessible. Problem solved.
  • russss 16y ago
    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.
    • jonhohle 16y ago
      But you would never `include()` a PEM file.
• drdaeman 16y ago
  Client SSL certificates? I don't know what DB they're using, but at least Postgres and MySQL support certificate-based auth.
  • pilif 16y ago
    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
    • drdaeman 16y ago
      .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.