Is it secure to use a PHP file with connection parameters, and include that file to the page?
example:
include("connect.php");
connect.php:
$con=mysqli_connect('localhost','root','','database')
or
die(mysqli_connect_error($con)."- In line: ".__LINE__);
mysqli_set_charset($con,'utf8');
Yes, because the include is happening server-side. You should look up some information about server-side programming and client-side programming!
Also MySQL functions are officially deprecated and MySQLi or PDO should be used instead!!!
Yes, this is fine though it might be better if you used require() so that if for whatever reason including the connect info fails, the code execution stops. include() will continue to execute the script even if the command did not succeed, which can cause error information and/or information only required if a connection is successful to be exposed (not generally recommended).
For even more security, you can move the connection info file out of the public web root (e.g. if web root is /home/data/files then moving it to /home/data then including /home/data/connect.php or ../connect.php - if your web host allows this). This will mean it cannot be accessed via HTTP.
Related
Just wondering is this could be a potential security problem with MySQL and PHP:
I have a connect.php file on a server, if someone used require(http://myurl.com/connect.php/);, would this allow them access to my database?
Thanks in advance
No, but for additional security, it's best to keep your sensitive files outside of the web root, in case a misconfiguration of your webserver breaks PHP and exposes it as plain text.
No, that would not allow them to connect to your database. When they require your connect.php over Internet, they get what is produced by this php script as output. In your case, your php script (connect.php) probably produces nothing as output (it just connects to db and terminates.
No, PHP variables are not accessible client side. For example a file like this
<?php
// Create connection
$con=mysqli_connect("example.com","peter","abc123","my_db");
// Check connection
if (mysqli_connect_errno())
{
echo "Failed to connect to MySQL: " . mysqli_connect_error();
}
The $con variable would not be accessible publicly.
Probably not. If "someone" does require(http://myurl.com/connect.php/); from his server (and has the inclusion via http enabled, see http://www.php.net/manual/en/function.include.php), then his server connects to your server and fetches the interpreted output of your connect.php.
If you have 'server side include' enabled - yes.
Read about allow_url_include directive: http://www.php.net/manual/en/filesystem.configuration.php
Is it possible to hack website by sending PHP variable from another host? For instance:
I have a file secure_content.php:
<?php
if($fgmembersite->Login()) //placed at the top to avoid the warning: headers already sent
{
$login = TRUE;
}
//intentionally removed {else $login === FALSE}
// echo some contents
if ($login === TRUE)
{
//echo secure data
}
else
{
echo "You are not authorised to view this content";
}
?>
And an attacker have a file in his webserver named: hack.php
<?php
$login = TRUE;
require_once "http://mywebsite.com/secure_content.php";
?>
Is it possible the hacker to view the secure content?
How to avoid processing our scripts using include/require from other webserver?
No, it isn't possible to process your scripts from another webserver.
Your server will not give the entire PHP source code to the remote server, rather it will give the output of running your script.
No worries here.
You cannot avoid processing your scripts using include from other webserver, because that is not possible in the first place. So there is nothing to prevent.
As Denis said, though I want to add few interesting caveouts from personal experience administrating sites.
People often rename their php scripts into something like secure_content.php.back while editting the file - fear it. As then, the attacker can download your PHP script accessing (secure_content.php.back). Having source-code is not enough to hijack variables, but is already a vulnerability. It will get amplified, if your secure_content.php.back has some configuration variables like $database_password
Also, if you are to uninstall PHP from your web-server, Apache (or whatever) will serve your secure_content.php as a text file - is also a risk. Just keep in mind when you are to tinker with your PHP engine.
No. Your server will run the script and then send the results to the evil server.
A similar thing to what you mention can occur in older versions of PHP if register_globals is on. This would allow someone to call http://mywebsite.com/secure_content.php?login=true.
This would cause $login to be set to true at the start of the script. Thankfully register_globals is now off by default and is deprecated in 5.3 and removed in 5.4. See here.
I'm just writing a PHP file to connect to my SQL server for a website login system and I'm terrified I'm just going to leave massive security holes.
I have my connect.php file in a directory of the websites root directory with this in it:
$db = new mysqli('localhost', 'publicguest', '**********', 'website');
where the password is open to see. I know when someone is looking at the website they cannot see the PHP code through the source but is this insecure and what is the common way to avoid this?
If your server has configuration issues, specifically php scripts aren't executed then someone may be able to get that info.
To avoid that you can put the file above the document root directory.
Unless they have direct access to the files you're working with, it should be fine.
Most commonly, people will store passwords and settings in a configuration file above root level which they then parse and use in those statements. It will then be up to the attacker to reach that file.
If you really want to be obscure about it, you could encrypt those settings as well.
Unless an attacker has FTP/direct access to the files, this is not a security risk as the PHP file is processed before outputting it to the client.
If the attacker has FTP/direct access, the mysql auth info is the least of the problems!
Wordpress stores the mysql login info in clear text in the wp-config.php, joomla does the same, there is no other way to do it i think.
For a good practice you shouldn't use your password in the source code of your application, but rather store it in a db_config.php file outside your web root, making sure your config file is not publicly accessible.
This should get you deeper into the argument:
http://www.mediawiki.org/wiki/Manual:Securing_database_passwords
For the most part its safe, unless:
For some reason your web server spits out your code in plaintext, this can happen in rare cases with server misconfiguration.
You can store your connection data outside of the web root to stop general access, but in the event a hacker has been allowed to execute PHP on your server for any reason, its game over anyways.
The only thing I would change about that line of code is getting the username and password out of that particular line, eg:
$host = 'localhost';
$user = 'publicguest';
$pass = 'hunter2';
$database = 'website';
$db = new mysqli($host, $user, $pass, $database);
The reason for this is if, at some point, your code encounters and error and spits out a stack trace it will not accidentally spit out your connection information as well.
If you really wants to be paranoid you can call:
unset($user);
unset($pass);
After the connection goes through, but that really only protects you from code injection, and so long as you never ever use eval() you should be fine. [seriously, never. >:I]
Anything further that people in this thread are suggesting is just paranoid faffing about because once someone has file-level access to your code they have the keys to your kingdom anyways and it's game over. But take heart! 99 times of 100 no one cares about your code or your database, they just want to inject their own code to send spam and/or DOS other people. :P
Why doesn't this work?
// File hosted on `example.com`
// db-con.php
<?php
define("DB_HOST" , "host");
define("DB_NAME" , "name");
define("DB_USER" , "user");
define("DB_PASS" , "pass");
-
// File hosted on `another-example.com`
// index.php
<?php
include 'http://example.com/db-con.php';
echo DB_HOST;
-
// output
Notice: Use of undefined constant DB_HOST - assumed 'DB_HOST' in C:\Users\Alex\Dropbox\Shared\Web\htdocs\BASE_TEMPLATE\index.php on line 14
Surely by including the external file, the php is run, and the constants are defined?
You are not including the file as you see it, but instead including the response of the remote web server when that file is requested.
That is, the remote web server sees a request for db-con.php, loads it up, executes the code (defining constants in its own local process) and returns the output to you (which is probably empty, as the code does not echo anything). Therefore the end result is the same as if you had included an empty file.
Update: dug up the reference from the manual:
If "URL fopen wrappers" are enabled in PHP (which they are in the
default configuration), you can specify the file to be included using
a URL (via HTTP or other supported wrapper - see Supported Protocols
and Wrappers for a list of protocols) instead of a local pathname. If
the target server interprets the target file as PHP code, variables
may be passed to the included file using a URL request string as used
with HTTP GET. This is not strictly speaking the same thing as
including the file and having it inherit the parent file's variable
scope; the script is actually being run on the remote server and the
result is then being included into the local script.
So how to do it?
Well, including code from a remote server is something you shouldn't really think of doing (although there are ways to make it happen, it's a really bad idea). In any case you won't be able to do it without the explicit cooperation of the remote server (otherwise anyone could include anyone else's configuration file and use get_defined_constants to get the passwords). And if you do it, anyone else would be able to follow the same steps and get hold of your passwords. You don't want that to happen.
I am trying to include remote php files as a resource but I am having a bit of trouble. I went into the php.ini files and set allow_url_fopen to ON. I also looked for the setting allow_url_include but it was not in the file, I added it to the php.ini file and also set that to on.
If I try to include using
include ('http://somewebsite.com/lib/somescript.php');
The server / php spits out a message saying:
URL file-access is disabled in the server configuration
I also get a message saying:
failed to open stream: no suitable wrapper could be found in blah blah blah
The seconed way I am trying to acomplish the same result is using fopen but I am just getting the content of the file, thats not what I need I need my local script to see the remote script as an executabel rescource.
$myscript = fopen("http://someotherwebsite/lib/my_script.php", "r");
$incmyscript= fread($myscript , 9999);
fclose($myscript);
// include in the contents of my_script.php
echo $incmyscript;
I have to be doing something wrong? I know echoing out the variabel $incmyscript is wrong, but I can't think of a way to place in the code. I am not sure if fopen is the best best way to get what I want.
Any ideas?
The message you are getting:
URL file-access is disabled in the server configuration
Indicates that the allow_url_include setting in your php.ini is set to Off. Enabling that option will allow you to do remote file inclusion, but be very careful with this as it's a pretty big security risk once the other site would be compromised (A hacker could easily inject their own remote code to your site).
Instead of echo, you could use eval.
Only do this if you want to execute PHP code from the other server, not if you just want to include HTML!
Even if you really want to execute PHP code from the other server, a man-in-the-middle could execute arbitrary PHP code on your server. You should therefore better use HTTPS or avoid the inclusion of the remote file at all.
Example:
$myscript = fopen("https://someotherwebsite/lib/my_script.php", "r");
$incmyscript= fread($myscript , 9999);
fclose($myscript);
$incmyscript);
Instead of the echo you could use this:
eval($incmyscript);
But be careful, this is very bad practice!
READ THIS: http://php.net/manual/en/function.eval.php
If you can trust remote script then you can call eval:
eval ($incmyscript);
If http://somewebsite.com/lib/somescript.php served by server supporting PHP you're trying to include it's output, not the code itself! Otherwise it's a just wrong and may be considered as security hole!
What you're trying to do is opening of a major security hole!
If the remote server is configured to process .php files, you won't be able to get the source for it. The server will process the PHP and then return any output. If getting remote PHP sources were possible, hackers would be grabbing our code and looking for vulnerabilities way too easily!