I have a php script PayPal eStores/dl_paycart but it has PayPal eStores "settings.php" Security Bypass Vulnerability
I would like to know if I can prevent direct access to a php include file.
Would this help?
defined( '_paycart' ) or die( 'Access to this directory is not permitted' );
Thank you
I would STRONGLY recommend finding some new script. Any sort of blocking is just sticking a finger in the dam; it isn't a permanent solution and eventually it's going to break.
If you really want to use it, check out htaccess files, particularly "Order Allow,Deny" and "Deny from All"
The problem is that if someone is able to use "include" and read the code contents, variables, and the like, that means that they are already operating on the same server and, to be a bit crude, you're boned if they try to screw with you.
On the other hand, if you're looking to prevent outside access to the file from a remote server, then the include call can only retrieve the values which would be displayed to any external site (and if the question is, "Can I prevent external sites from even loading this file remotely", the answer is "through server configurations in http.conf and .htaccess files" ).
The long and the short, however, is that this is not something which can really be fixed with PHP, this is a server security issue.
The fact that the script has a .php extension offers some protection - any http or https call for that file will go through the web server which is going to execute the php before serving the request.
I would recommend moving the script to a directory under your public web directory and putting .htaccess file in that directory that either blocks all requests, or requires a password to access it. Then include the script when needed by scripts in your public directory. See Apache's .htaccess Tutorial
Probably the most secure way is something like this
$allowed_files = array("/paths/", "/that/", "/are/", "/allowed/");
if(!in_array($_SERVER['PHP_SELF'], $allowed_files))
{
die("Not Allowed");
}
Fill the array with Files that you would like to have access. (You might have to access PHP self in each page you want and copy and paste it in). This will check to make sure that the file being executed is one of the allowed pages. If it isn't the script will die.
I believe $_SERVER might be able to be changed, but probably won't be. This file will still be able to be gotten using fopen or file_get_contents, and if someone reads it, they will know what to change.
But I would forewarn, it is not 'completely secure', because there isn't really a way to make something 'completely' secure.
Related
Gone through related posts and found turning allow_url_include will does the trick. However when I did this :
remote file file.php at http://www.courierscripts.com
$content = file_get_contents('http://www.courierscripts.com/folder/file.php');
on my functions.php, was not able to use the functions of file.php. I also don't want to change my file.php to file.txt because everyone can see it.
Any other way?
If the file is on the same server, use absolute or relative path to it, not an url. Otherwise:
Short answer:
No, it's not possible.
Long answer:
Actually possible with conditions but I bet you won't like them.
It's obviously impossible if you don't have access to the target server (otherwise storing passwords in php config files like Wordpress does would be just one big security flaw).
First of all, file_get_contents returns a string. So you could eval it, but eval is very bad (you can search SO for the clues why).
OK, suppose you agree to eval what's coming from that server even after considering that someone might change the code and do whatever he wants on your machine. BUT you make an http request that is handles by the server (Apache, Nginx or whatever else).
The server knows that *.php files should not be handles as static files. For example, fastcgi. You can turn that off, for example, with RemoveHandler in Apache. But that would let everyone see the source code of files you expose this way.
So, after removing handlers and evaling the result, you could get the result. But be ready that someone you work with will punch you in the face for doing that ;)
UPD
For code sharing, use Composer to create a package and use it as a dependency.
I need to connect to a mysql database using PHP. I am storing my login, user, password, and other info in a separate php file (let's say "mysql_connect.php") and then accessing it via require_once (mysql_connect.php) in a different file.
I have done a bit of googling and I know that I am supposed to keep "mysql_connect.php" out of the web root. I have moved it outside of the html folder and tried calling to it by using "../../mysql_connect.php" This is not working, it gives me an error "function not found" or something like that. Upon googling that, the internet says that its because it can't locate the file i'm referencing. When I move mysql_connect.php into a folder below root, everything works fine. The issue is because it is moved outside of the web root (i think).
I have been googling for two days now and cannot find a detailed explanation on how to get this to work. Something about changing the .htaccess file? I've read a bunch of articles on the theory but I am really looking for a step-by-step tutorial (I am a beginner). The only step-by-step tutorials I can find just tell you to put the config.php file into the same folder which is not secure.
Also in reading, it says that putting mysql_connect.php above root might not be THE most secure way to store the information as it is still basically just a .txt file and it can be retrieved easily(like downloading it). I am looking for a balance between secure and also do-able (for a beginner like myself). The mysql database I am trying to protect will not have any personal information and I plan on using a dedicated server (with no other information on it).
Can any one help me to solve this issue?
it gives me an error "function not found" or something like that.
This.
Is your main problem.
You either didn't bother to read this error message yourself nor didn't bring it here to help us to help you.
While
there is no problem in having this file below document_root,
and there is no problem in having this file above document root either,
the only problem you have is to assign a correct filename.
And the error message you got could help you more than 1000 volunteers from this site.
Despite of that, you can use PHP predefined variable to make this path work from whatever part of your site. Aassuming the file is one level above the document root, the code would be
require($_SERVER['DOCUMENT_ROOT']."/../mysql_connect.php");
however, this one may produce an error too, as nobody knows a real file locations. Thus, you may read the error message and corect the paths. Or post it here and get an interpretation
You can store the database information inside your web server configuration.
If you run Apache you can use SetEnv inside the VirtualHost. Since you're still on a shared host, your server admin probably need to help you with this. You can read more about this approach here.
... tried calling to it by using "../../mysql_connect.php" This is not working, it gives me an error "function not found" or something like that.
Include the connection details with:
require_once("../../mysql_connect.php");
This assumes that the file mysql_connect.php is two levels up from the currently executing script.
The database connection details will always be able to be read by whomever has administrative access to the server. It is not feasible to encrypt the file, because you would still need to store whatever key or password needed to decrypt it on the server as well, which would still not hide it from the server administrators.
Besides moving out of the web-root (which is a good step forward) an approach I've seen used is:
// at the top of your index or bootstrap file
define('SECURED', true);
And:
// at the top of any file subsequently included, such as mysql_connect.php
if(!defined('SECURED'))
{
exit();
}
This will at least prevent the file(s) from being accessed (executed) directly. This is helpful is the to-be-included files would otherwise issue a warning or error, that could potentially dump sensitive data as output.
If you're in a shared hosting environment you won't be allowed access outside of document root (most likely). You will need the password therefore it won't be completely secure. Instead, you can look into creating seperate mysql users with priviledges and limiting connections to to local accesses only.
i know i'm new, but something as simple as form for your login should be checked in order for it to work.
<form action="insertphpfilepath.php" method="POST">
and then in "insertphpfilepath.php", would have the mysql_query to check the login and password, not forgetting the mysql_query for connecting to the database and table using the right username and password .
a newbie recommendation to you for use mysql_real_escape_string for any $_POST['login'] so that it would become $login=mysql_real_escape_string($_POST['login']); for evading mysql injection.
I am a PHP newbie and a have a php security question. Is it possible for somebody to get the source code of a php script file running on a server with default configuration? If so, what is the best way to be protected? I am asking this because I happened to download a php file when I requested a page from a site and what triggered my concerns. I think that maybe apache configuration was wrong and served that file to me like a simple file but I am not sure. Also what is the best place to keep "sensitive" data such as database or smtp configuration?
Thank you,
Alex
For the most sensitive information, I'd suggest putting it outside of your web root folder, and including it through "require" or "include". This way, even is some configuration gets botched on the server, the visitor will only get served the line "include('secret_stuff.php');" and not the actual script.
Exactly what David Dorward said but i would advise you take a look at the following patch(s) that would modify apache to not send source code's regards if there is a misconfiguration.
http://mirror.facebook.net/facebook/patches/ap_source_defense.patch
Patch like so:
cd apache-1.3.x
patch -p1 -i ap_source_defense.patch
More Patches from Facebook Development Team: http://mirror.facebook.net/facebook/patches/
The best way to protect your much needed source is to place them outside the public root directory, as if apache is running it will not be able to serve files directly from the folder up public_html
for example:
C:/server/apache/
C:/server/apache/htdocs/
C:/server/apache/htdocs/includes/
People can specifically view the files my going to
http://hostname.tld/includes/
but having the directory structure of:
C:/server/apache/
C:/server/apache/includes/
C:/server/apache/htdocs/
and then within
C:/server/apache/htdocs/index.php
you have
<?php
require_once('../includes/config.php');
?>
this should protect all major files bar the view file (index.php)
If the server is not configured to handle PHP files, then it will treat them like any other unknown file (and serve them as either text/plain or application/octet-stream.
PHP support is, as far as I know, always provided as an extension or external program (for CGI, FastCGI, etc) and never as a built in for an HTTP server.
If the server is properly configured to run PHP code, then people without direct access to the server cannot view the PHP source code. You don't have to do anything else.
It is only because that server was not configured to run PHP, and instead served it as text, that you could see the source.
If you have this line in your apache.httpd.conf file,
AddType application/x-httpd-php .php
Apache should deal with data, rather than showing them...
Also you need to start php services.
What you describe as "default configuration" is a webserver without php installed (or with php disabled). In these cases, it is certainly possible to download the php script.
Make sure php is installed (as it will be on ~100% of production php servers) and/or block access to your configuration file with an .htaccess file like this:
<FilesMatch "^config.php$">
Order allow,deny
Deny from all
</Files>
If you want to be extra-tricky (and work even on servers where .htaccess files are ignored), prefix the configuration file with .ht, like .ht.config.php. Most Apache(and some other webserver) configurations will refuse serving files beginning with .ht. However, in general, the only way you could be sure no webserver serves your file is to move it to a directory outside of the server's document directory. On most hosts you or your php script won't be able to access those though.
Your second problem are misconfigurations. There's not much you can do, albeit there might(?) be options to construct a rewriterule to prevent accidential accessibility.
The best prevention however is to keep all scripts outside of the DOCUMENT_ROOT. Just leave a single index.php there, and include all dependencies from there. This is also the best strategy to avoid leaking of configuration data (also don't use ini files for sensitive data, but always .php scripts).
Another worry are shared hosting servers however. All concurrent users on a server can read out your scripts (if not through PHP then via Perl/bash CGIs). Nothing you can do about that, unless you change to a professional hoster which supports running everthing through suexec and thus allowing individual permissions.
Well, "default configuration" is a vague term, but as long as the web server is configured to parse .php files through PHP, you should be fine from that angle. If your scripts themselves happen to parse other PHP files (for eg. a template system) then you need to make sure there aren't any loopholes in that too, since the PHP scripts have full access to your files on the server.
Assuming these are taken care of, you don't need to keep the "sensitive" data in any special place -- just put them in your .php files, but make sure all your scripts end in .php (for eg. config.inc.php) so that they are always parsed via PHP and not sent as plain text.
This may be a really stupid question...I started worrying last night that there might be someway to view PHP files on a server via a browser or someother means on a client machine.
My worry is, I have an include file that contains the database username and password. If there were a way to put the address of this file in to a browser or some other system and see the code itself then it would be an issue for obvious reasons.
Is this a legitimate concern?
If so how do people go about preventing this?
Not if your server is configured right. I think discussion on how that is done belongs on serverfault.
To add on to the other answers:
If you use a file extension like .inc there's indeed a higher risk. Can you open the file directly in your browser?
The most important advice is missing:
Only the files that should be accessed by a browser, should be in a publicly accessible location. All the other code (and configuration) should be in a completely separate directory.
For example
root
- webroot
- includes
- config
Only 'webroot' is exposed by your webserver (apache). Webroot can for example contain a single index.php, along with all your assets (javascript, css, images).
Any code index.php needs to load comes from 'includes' and all the configuration from 'config'. There's no way a user could ever directly access anything from those 2 directories, provided this is done correctly.
This depends on the file extension you have given the include file.
If the extension is one that is known and executed by the web server, it will be protected. If you browse to the file, the server will try to execute the code rather than just returning it as plain text.
If the extension is not known by the web server it will serve it as plain data, so anyone (who can guess the file name) can browse to the file and see the source code.
A Directory Traversal Vulnerability can used to obtain files off of the remote mahine. Alternatively you can use MySQL based sql injection to read files using load_file(). You can also test your system with w3af's urlfuzzer which will look for "backup files", such as index.php.zip. Also make sure that all files have .php extensions, a .inc can be viewed from the public. I would also disable Apache directory listing.
Normally there should be no way to view the PHP files remotely... it would be absolutely pointless. This completely depends on what web server you are using and how it's setup though.
Having looked around I can see that it is possible to protect a directory via the .htaccess by adding these lines:
Order allow,deny
Deny from all
This apparently protects the directory so that only local non web-access is possible.
This allows me to keep my includes in a subdirectory of the main site directory which is good for organisation and it can be used on the projects where I do not have access to folders outside the web root.
Does anyone else use this method?
Just for good measure I've put the directory permissions to execute only.
And the include extension is PHP as suggested by others.
I would like to ensure that any scripts that are trying to "include" my database connection file are located under my own domain. I don't want a hacker to include the database connection file to their malicious script and gain access to my database that way. My connection file's name is pretty easy to guess, it's called "connect.php". So without renaming it and taking the security through obscurity route, how can I protect it by making sure all connection requests are made by scripts residing under my own domain name? How can this be checked using PHP?
Generally speaking if someone tries to include a file on your domain, they will see the results of the execution of that file. What do you see when you load the connect.php script in your web browser? Thats what they'll see as well if they try to include a remote file.
That said, its generally a good idea to keep important files inaccessible from the outside of your public web space. So, if your website is /var/www/yoursite/ then keep your connect.php in /some/dev/dir/yoursite and include the files from your pages using require_once '/some/dev/dir/yoursite/connect.php';
thetaiko's answer addresses the fundamental issues here - but if anyone else has access to run code on the server (i.e. its a shared server) then access to the file will depend on how the server is configured.
There are lots of ways that access might be constrained - e.g. suphp, base_opendir, multiple chrooted servers. The only way to find out what's going on for sure is to casr yourself in the role of the hacker and see if you can access files outside your designated area.
C.
What do you mean by including your connection file? If a script does include "connect.php" then they can see the source code of the file, so whatever security measures you add to that file will be pointless, as it will be like:
if($notFromHostname)
{
echo "DONT LOOK AT THIS";
die();
}
define('DB_PASS',"myPassword");
...
And the "hacker" will clearly be able to see your password. You are probably better off using something like iptables to deny hosts that are not from a specific domain.
Are you on a shared server and don't want other users of the same server instance to be able to get at your files? That'd be up to your server provider, then, to provide some sort of chroot or virtual system to keep your things in. For Apache, mod_suid can accomplish this nicely, and each vhost gets its own userid and permissions set.
If you want external users to not be able to get at your files, then unless you've badly munged your code, or the server's badly misconfigured, then all they'll get when they visit http://yourserver.com/connect.php is a blank page
No other user than yourself should have access to your PHP files in any way, as Felix mentioned. However, this is how you'd check in PHP:
if($_SERVER['SERVER_NAME'] != "example.com")
die("I've been kidnapped!");