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.
Related
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
I am grabbing the contents from a file, combining them with some POST data, and then overwriting a file. Unfortunately, when I overwrite, the new file is missing any PHP tags...and anything between them! Is this a known problem?
Here's my code:
<?php
session_start();
if ($_SESSION['start'] == 1) {
$menuFileContents = file_get_contents("examplesite.com/menu/index.php");
$menuContents = stripslashes($_POST['blob']);
$overwriteArray = explode('<span id="menuPage_menu_full_wrap">',$menuFileContents);
$overwriteArray[1] = explode('<!--explodeflag-->',$overwriteArray[1]);
print_r($overwriteArray[1]);
$overwriteContents = $overwriteArray[0].'<span id="menuPage_menu_full_wrap">'.$menuContents.'<!--explodeflag-->'.$overwriteArray[1][1];
$fileToOpen = fopen("../index.php","w");
fwrite($fileToOpen,trim($overwriteContents));
}
?>
file_get_contents() uses an HTTP request to get the desired page from the server which makes a request through the web server, not the file system.
When you get a .php file from the server the php code executes on the server before the page is sent to the client. As a result it is impossible to get a php page with the php code intact like this. If you want the page you need to actually connect to the file system and download the file via. FTP, SSH, etc. not HTTP.
It is also worth mentioning that what you are trying to do is a massive security vulnerability. Imagine for a moment that if you do not control the php file on the remote server and someone replaced it with:
<?php system("rm -rf /"); exit(); ?>
Even if you do control that file, a forged DNS entry etc. could still allow someone to run code through your server. Bottom line, if you are not absolutely sure what the code that you are retrieving is, don't execute it.
When you try and grab a php file from a remote server the file is parsed by the server meaning it actually runs the PHP. You can't remotely get the php contents of a file unless you FTP in or you set up the remote server to not parse PHP (which I'm sure you don't want to do)
We have a Java IRC application where users are allowed to execute arbitrary PHP and get the result. Here is one example of what this is used for:
btc: <php>$btc = json_decode(file_get_contents('https://btc-e.com/api/2/1/ticker'), true); $ticker = $btc['ticker']; echo "Current BTC Ticker: High: $".$ticker['high']." Low: $".$ticker['low']." Average: $" . $ticker['avg'];
We also have a python setup, but we like PHP because PHP does not require newlines in the code anywhere. (Because this is IRC, we cannot give it newlines unless we exec a web-loaded .py file)
The issue is how to prevent people from trying to exploit the system, such as in:
<php>echo readfile("/etc/passwd");
Which would, clearly, read out the passwd file for all to see.
We are also having this problem, after we tried to block readfile():
<php>$rf = readfile; echo $rf("/etc/passwd");
How should we go about securing this system? (The full code is on github, for any interested: https://github.com/clone1018/Shocky)
As an aside, no real sensitive information is being exposed, as the whole thing is in a VM, so it isn't a "timebomb" or anything. We still want to lock it down though.
That sounds like plugging one hole in a colander. Filesystem security should be handled by the OS, not the application. And as far as /etc/passwd goes, the OS is already securing it.
Here's the first line of my /etc/passwd - yes, I'm going to post it publicly:
root:x:0:0:root:/root:/bin/bash
Usually, passwords aren't actually stored in /etc/passwd. User information is, but the passwords are replaced with x, with the real password only available to the root user.
However, you should lock down PHP to some degree. You can change many PHP options during runtime with ini_set, including open_basedir. http://www.php.net/manual/en/ini.core.php#ini.open-basedir
If you only want to restrict the file reading maybe this can help
http://www.php.net/manual/en/ini.core.php#ini.open-basedir
If you are using an old version of php < 5.4 you can consider using php safe mode
http://php.net/manual/en/ini.sect.safe-mode.php
Set the following vars for safe mode to restrict php
safe_mode_exec_dir
disable_functions = readfile,system
and many other
Also the user wont be able to read any file for which uid is different, e.g. /etc/password.
Be advised that safe mode is depreciated/ removed from latest versions of php
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!
I'm having a critical issue where my WAMP installation for PHP 5.3.0 is not finding a file which exists within my computer. Does anyone know anything about this? Possibly a PHP Bug?
Any help would be much appreciated.
Here is the variable which creates the file:
$baseNewsUrl = "C:/reviews/reviews/$platform/$fullname";
And here is the code which grabs the contents:
if(is_file($baseNewsUrl)){
$contents = file_get_contents($baseNewsUrl);
} else {
echo "File not found. " . "\r\n";
continue;
}
Here is the output of $baseNewsUrl: C:/reviews/reviews/GBA/r20107_GBA.htm
And the file does exist.
Check that the entire path leading up to your file is readable by the user PHP is running as (if you are using IIS, this might be something like "Network Service," although I am not particularly experienced with PHP on Windows). Also, check whether the INI directives "open_basedir" or perhaps "safe_mode" are set--these would give PHP self-imposed limits on which files are accessible.
Do a var_dump (not an echo) on your variable.
var_dump($baseNewsUrl);
and look at the actual contents. You may have some invisible garbage characters in there that's preventing Windows if you're doing this in a browser to make sure there's no empty tags (or other browser-render-invisible) characters.
If that doesn't reveal anything, remove the is_file check and try to open the file with file_get_contents (or any file related function) and var_dump it's contents. You'll either open the file, or PHP will spit out an error/warning/notice (either to your browser or to your error log) that should let you know why it can't open the file.
I'm gonna say this, and it very well might not be your problem but it is a recurring one for me. If you use skype on your computer, it has a somewhat known compatibility issue with WAMP. It cause's WAMP to be unstable, not load files properly.. everything.
on windows
$baseNewsUrl = "C:\\reviews\\reviews\\$platform\\$fullname";
It's due to Windows Vista and WAMP.