1

I have a small page that contains the connection data to my MySQL DB, which I include in other pages that require it. The small code is:

[connect_DB.php]
----------------
<?php

define("HOST", "localhost");
define("USER", "myUser");
define("PASSWORD", "myPasword");
define("DATABASE", "members");

$mysqli = new mysqli(HOST, USER, PASSWORD, DATABASE);

?>

A friend of mine proved to me that he can download the .PHP file, and in less than 2 min, he did. That means he got the login info for my MySQL server. And I was wondering if there existed another way of connecting with the database, without putting the password in a file, etc. He recommended me use SSL or TSL, or simply configuring the HTTPD.CONF or .HTACCES to not allow "exterior" access to the file. Is that correct or achievable?

I am actually testing this on Wamp Server (Win7), and I cannot create a .HTACCESS file because It tells me to enter a name for the file (which I am already introducing! :( ) every time I try to name it that way.

I understand that this may be a duplicate question, but believe me I read a lot of t hem but I don't understand what should I do. In advance, thank you.

MoeSzislak
  • 137
  • 1
  • 4
  • 13
  • 1
    You just have to forbid downloading any files from root non-html directory in apache settings. – sybear Jun 24 '13 at 13:26
  • 3
    you hold the password in a file that's not accessible by `www` – Kermit Jun 24 '13 at 13:27
  • 3
    pretty hard for the webserver to connect to the database if the password is not accessible to it. – Gerald Schneider Jun 24 '13 at 13:28
  • 2
    Its a server config error if he was able to download a php file without it being processed by the php engine. Otherwise if it was processed he just downloaded a blank file – Dave Jun 24 '13 at 13:30
  • He did it with a program Website Ripper Copier I believe..., it draws the site tree, downloads the files with the code, etc. – MoeSzislak Jun 24 '13 at 13:33
  • 3
    Doesn't matter what he used it still did a HTTP request and so the web server must have compiled the file and sent the output of the file being executed. Which in this case is blank. Now if he screenscraped the output from the front end pages thats different but that file specifically himself naah. not if the server is configured correctly. – Dave Jun 24 '13 at 13:34
  • 1
    1. Open Notepad or any other text editor. 2. Put in what you want in the file. 3. Go to Save As, and put ".htaccess" for the filename, including the quotes. – Daniel W. Jun 24 '13 at 13:34
  • If you can tell us (and if your buddy is nice enough to) how he did get to download the source file, we can suggest more security advices to you. Maybe he just used your windows file share like `\\c$\wamp\htdocs\db.php` – Daniel W. Jun 24 '13 at 13:36
  • 1
    @DanFromGermany that comment is not very helpful. you just can't put whatever at least suggest a directive. – DevZer0 Jun 24 '13 at 13:36
  • 1
    Great trick for the .htaccess file, thanks. – MoeSzislak Jun 24 '13 at 13:37
  • @DevZer0 Moe said it was very usefull for him. I really don't understand why you don't like my comment. – Daniel W. Jun 24 '13 at 13:39
  • 1
    @GeraldSchneider I suppose what FreshPrinceOfSO meant is that you might consider putting the DB connection file outside the docroot of the server. You can include it perfectly fine with PHP (provided that open_basedir and such is configured correctly), but you couldn't access the DB connection file directly over HTTP. However, that's obviously not the problem here, but putting it outside docroot may add a little security. – stef77 Jun 24 '13 at 13:41
  • @DanFromGermany it would have been better if you actually told him what he needs to put on .htaccess file. – DevZer0 Jun 24 '13 at 13:41
  • @stef77 that's a good clarification, i was wondering why he suggest the file not be readable by `www` user or something. which then it would not work – DevZer0 Jun 24 '13 at 13:42
  • Thanks. Besides, I suppose this question is a duplicate anyway, check e.g. http://stackoverflow.com/questions/5121495/php-code-is-not-being-executed-i-can-see-it-on-source-code-of-page - **if** the source was really displayed when access via HTTP. – stef77 Jun 24 '13 at 13:45
  • `.htaccess` doesn't prevent downloading the file via ftp/share/... You can put something like that in it: ` deny from all ` It would be really usefull if we get to know how he could download the file. – Daniel W. Jun 24 '13 at 13:46
  • He did it with the program I mentioned before (Website Ripper Copier) which allowes you to save the whole site AS only .htm files BUT inside you can see all the source code, PHP, ASP, etc. Wierd... AND, @DanFromGermany, that is what I was looking for, but when I am going to upload the web to a host, I am not going to find any file called httpd.conf, and neither a www directory. Or they are hidden? – MoeSzislak Jun 24 '13 at 13:49
  • @MoeSzislak it depends on the host. The www directory called be called public_html or something else. also if you're on a shared server, most likely you wouldn't have access to httpd.conf. VPS and Dedicated you'd have more control. – Panama Jack Jun 24 '13 at 13:55
  • @MoeSzislak what happens if you open the file in a web browser (http://yourhost.tld/path/connect_DB.php) and then view the HTML source contained in the browser - do you see a blank page or your PHP code? – stef77 Jun 24 '13 at 13:58
  • blank page, the PHP engine is running correctly. – MoeSzislak Jun 24 '13 at 14:04
  • Ok, so your friend did not download the source from your web server via HTTP. Couldn't you ask him simply in the first place just what he did exactly? It's of course still possible that he used some bugs in the web server used by some cracking tool or the other. Since he recommended using "SSL", which would have no effect if the server was configured wrong in a way that it sends PHP source (which it doesn't), perhaps he sniffed your FTP password while you uploaded a page and used this info to get your page by FTP? From the provided info, I fear that's as far as we will get with guessing. – stef77 Jun 24 '13 at 14:07
  • Well, I can't ask him, he is my teacher and he wants me to ""INVESTIGATE"". (lol) – MoeSzislak Jun 24 '13 at 14:15
  • ... I doubt that the answer you accepted as correct will help you then. There's nothing wrong with your server configuration and if the page you called by HTTP isn't displaying PHP source code, the problem is very likely to be found somewhere else. Try to remember: What was the situation before your friend showed you this effect? Were you perhaps on the same (unencrypted) WLAN and you uploaded files by FTP, and after that he showed you? Perhaps you could also play around a little with this Ripper program and try to find out if you can reproduce the same effect. – stef77 Jun 24 '13 at 14:24
  • Well, I don't know how legal is this, but my page is still inside the lan, in my computer. Conclusion, I don't upload my page anywhere, I just modify it in C:\ and see the results in "localhost" or "127.0.0.1". But he showed me the screenshot of the file, this cheeky bastard... Could this has something to do with the fact that I have the NAT enabled so I can have a public IP in my computer? And the fact that I deleted the variable "Require local" from httpd.conf? (I don't remember from which specified folder). – MoeSzislak Jun 24 '13 at 14:30
  • *** SO OK, this may be a bug or mistake of mine in my computer, but in a real host (say, 1and1) this would never happen right? no one could access my .php files, to see the source code? – MoeSzislak Jun 24 '13 at 14:33
  • @MoeSzislak I wouldn't say 'never' as providers make configuration mistakes too. It wouldn't happen there if you have PHP enabled. So some knowledge on security is always nice to have. – Daniel W. Jun 24 '13 at 14:37
  • 1
    I think now we're out of the scope of the original question. If you have your file only on your local machine and your friend can access it (and sees the source code), there's too many possibilities to guess what might happen. Maybe he called his buddy from GCHQ so he sent him some screenshots of your files, you never know. Might be anything. – stef77 Jun 24 '13 at 14:41

2 Answers2

1

Most likely, Your server is not setup correctly, meaning the PHP engine is not running, so its just sending or displaying the file contents back as say text/html and not being parsed by PHP. This is the only way that some tool like you mentioned in comment could possibly access the file, a tool like that would also not see the file if there was not a link to it somewhere, so perhaps you have Directory Indexes enabled to.

To test you have PHP enabled simply make a file and put in it: <?php phpinfo(); ?> if it displays your php info then im stumped, if not then its proof your server is misconfigured for PHP.

Though once fixed, it is good practice to put sensitive files outside of your web root. And not a good idea to set your values in constants as a function like get_defined_constants() will give access to the sensitive values. Just put them directly in the construct arguments.

if you want to block access to a directory where only PHP can access you make a .htaccess file with deny from all in it, this will cause the server to send a 403 Forbidden.

Lawrence Cherone
  • 46,049
  • 7
  • 62
  • 106
  • So, if I create a directory, ej. "connection", and inside it I put the connect_db.php AND the .htaccess inside which I put only and a single line "deny from all". This will forbid access to any kind of exterior access to the files BUT will not block me to `include` it in other php files. Is that ok? – MoeSzislak Jun 24 '13 at 14:00
  • Yeah PHP can access any file upto the servers base_dir set within your virtual host (if set). But if its a basic WAMP more likely PHP can go all the way to C: – Lawrence Cherone Jun 24 '13 at 14:03
  • The `deny from all` business is only considered by your web server. After all filters (allow, deny and so on) are satisfied and the web server allows access to your page, you're free to include whatever you want in your PHP scripts, .htaccess won't be regarded anymore. – stef77 Jun 24 '13 at 14:04
  • So, just to have it clear... httpd.conf is the global Apache filters, and the .htaccess has the local rules of each folder or child? They both can have the exact same type of syntax? – MoeSzislak Jun 24 '13 at 14:24
  • This is basically correct, although you cannot set every configuration directive in .htaccess, some you can only set in httpd.conf, and it's configurable in httpd.conf what you can override in .htaccess files (if anything at all). – stef77 Jun 24 '13 at 14:35
1

I am pretty sure that your host Provider is not parsing the PHP files, because it would not be possible to download the sources if they'd pass the interpreter.

Make sure you have PHP installed, configured and activated, contact your provider's support in case of questions. The easiest way to test this is to upload a file:

test.php

<?php phpinfo(); ?>

To protect a file it's enough to put the your database config php outside of public_html, html or htdocs directory (one of these is most likely to be your document root), where you still can include(); it via PHP.

Other solution is to protect the file via .htaccess where you put something like that inside the file and upload it to your document_root:

<Files db_config.php>
deny from all
</Files>

To add a little more security, you can protect the db_config.php by adding this on top:

if (!defined('IN_MY_PROJECT')) {
    die('forbidden');
}

and put this on top of your index.php:

define('IN_MY_PROJECT', true);
Daniel W.
  • 31,164
  • 13
  • 93
  • 151
  • Very helpful! Going to test it out tonight. Thanks :) And by the way, the `define('IN_MY_PROJECT', true);` I put it in the index.php only? Or in all the documents that use the `db_config.php` (like register.php, login.php logout.php, etc)? – MoeSzislak Jun 24 '13 at 14:19
  • Put it in all files. It prevents foreign scripts to include your config. It won't help if PHP isn't running correctly tho – Daniel W. Jun 24 '13 at 14:31
  • What if the foreign scripts chooses to `define('IN_MY_PROJECT', true);`? Or chooses to `file_get_contents('db_config.php');`? Is it really worth the effort to put these defines everywhere, i.e., against what scenario should they protect? If anything at all, this will prevent direct access via web server by HTTP, but that can be mitigated by putting the db config snippet outside docroot, as you also suggested. – stef77 Jun 24 '13 at 14:45
  • I usually don't do it because it is actually not worth. Knowing such a mechanism is not to bad either. Moving out of the document root is still the best solution – Daniel W. Jun 24 '13 at 14:59