I'm a CodeIgniter user and I'm taking a look at Kohana. First thing I noticed is that in the documentation every snippet starts with:
<?php defined('SYSPATH') or die('No direct script access.');
assuming I'll be using .htaccess for address rewrite, is this really necessary? Is it an alternative to .htaccess for the purpouse of avoiding direct access? Is it just a good practice for "defense in depth"?
If you are using a .htaccess file to protect your system files, this is not required. However, since kohana has to support non .htaccess use, we place that there in the core system files for some basic security.
It's used to make sure you can only access the scripts through index.php (where SYSPATH is defined).
It's another layer of security if your script files are in a web accessible location. This check will stop people from executing classes like http://example.com/application/classes/controllers/welcome.php
In reality the files should be outside of the webroot with the index.php referencing the right locations, but that's not possible all the time, so they have that check.
I guess you could get away with leaving it out if you have .htaccess protecting those directories, but it doesn't cost anything to have so you might as well just keep it.
Related
Is it possible to deny access to files and folders within the web root without using .htaccess or file permissions? A universal solution that works with all servers?
This relates to a flat-file framework I'm making with PHP where the requirement is basically "drag the project folder in the web root to launch the site." The other goal is for there to be a front-end interface where the client can log in and edit content.
I deal a lot with shared hosting accounts where I can't always change the web root. Additionally, I don't necessarily want to rely on developers manually setting file permissions. The reason why I don't want to use .htaccess is that, one, it relies on the host being an Apache server, and, two, it relies on specific Apache settings.
EDIT: specificity
This was answered here with a couple of really great answers you'll probably find useful:
Prevent access to files from Apache without .htaccess
The first suggests setting permissions to be inaccessible and CHMODDing them with PHP when you need to access them.
The second suggested you place them outside of your web root but keep them accessible by PHP (using include(), I would assume).
Either or should accomplish what you're hoping. (Wish I could comment stuff like this.)
I'm a Java (SE, EE) developer and I have been working with these techs for almost 6 years, I have also worked with php for non-web apps.
Now I'm required to build a site in php but I have googled a lot and I can't find a standard folder structure for a php site. As may you know in Java EE there is a defined structure and with the web.xml you can define security in order to allow or deny access to folders in the web root.
So the question is: Is there a standard folder structure to bring security in a php site?
If there is not, how can I prevent access to folders in my site, without the need to use .htaccess nor moving my folders to a private area in the web server?
There is no defined structure for PHP projects. Application frameworks invariably use well-defined structures, but that is decided individually by each framework. In addition, the developer can easily work outside these structures (the price being that "automatic" features of the framework might no longer work in some cases).
In order to prevent access to directories in your site you have to do one of the things you mentioned: either use web-server-level mechanisms such as .htaccess or move the directories outside the web root entirely.
That said, in many cases there is no explicit need for such security: by strictly limiting the pieces of code that can produce immediate effects (typically down to just one front controller that boots up the application) and making sure that data is contained inside PHP code (so that the web server will not reveal the contents of files) you effectively render direct access from the outside worthless.
We have a custom PHP/MySQL CMS running on Linux/Apache thats rolled out to multiple sites (20+) on the same server. Each site uses exactly the same CMS files with a few files for each site being customised.
The customised files for each site are:
/library/mysql_connect.php
/public_html/css/*
/public_html/ftparea/*
/public_html/images/*
There's also a couple of other random files inside /public_html/includes/ that are unique to each site. Other than this each site on the server uses the exact same files. Each site sitting within /home/username/. There is obviously a massive amount of replication here as each time we want to deploy a system update we need to update to each user account. Given the common site files are all stored in SVN it would make far more sense if we were able to simply commit to SVN and deploy to a single location direct from there. Unfortunately, making a major architecture change at this stage could be problematic. In my mind the ideal scenario would mean creating an account like /home/commonfiles/ and each site using these common files unless an account specific file exists, for example a request is made to /home/user/public_html/index.php but as this file doesnt exist the request is then redirected to /home/commonfiles/public_html/index.php. I know that generally this approach is possible, similar to how Zend Framework (and probably others) redirect all requests that dont match a specific file to index.php. I'm just not sure about how exactly to go about implementing it and whether its actually advisable. Would really welcome any input/ideas people have got.
EDIT AllenJB's comment reminded me that we have previously explored AliasMatch as a potential solution to this, we ended up with an general.conf file for a user that looked something like this:
php_admin_value open_basedir "/home/commonfi:/home/usertes:/usr/lib/php:/usr/local/lib/php:/tmp"
php_admin_value include_path "/home/commonfi"
AliasMatch (.*).php /home/commonfi/public_html/$1.php
AliasMatch (.*).html /home/commonfi/public_html/$1.html
You can set this up via the Apache configuration - you probably want Alias, but there are several options:
http://httpd.apache.org/docs/2.2/urlmapping.html
You certainly can build a "cascading" system as you describe (load local file, if that doesn't exist, load global file). The complexity is that the files are loaded in different ways (using include() in PHP, through the web, ... maybe even more ways?)
Filesystem includes
If the includes/ consist of files containing one PHP class each, you could use an autoloader like Zend Framework does. The autoloader would look first for a custom version of the include file, and if it doesn't find one, include the global version instead. I happen to have such an autoloader handy if you need code to start with.
If the includes don't match the one-class-per-file structure, you would have to build a custom include() function that fetches the local version of the file or, failing that, the global one.
Pseudo-code:
function fetch_path($name)
{
if (file_exists(LOCAL_DIRECTORY."/$name")) return LOCAL_DIRECTORY."/$name";
if (file_exists(GLOBAL_DIRECTORY."/$name")) return GLOBAL_DIRECTORY."/$name";
return false;
}
Web resources
The second part is going to be the web part (i.e. Web URLs with local or global files). I think this should be pretty easily solvable using the -f switch in a .htaccess file. You would build a rule that rewrites failed requests (!-f) to the local web resources directory (example.com/css/main_stylesheet.css) to the global one /home/commonfiles/public_html/main_stylesheet.css). You would need to fiddle around with Apache's server config to be able to rewrite local requests to the commonfiles directory, but it should be possible.
That is maybe worth a separate question.
I’m new to CodeIgniter, I was wondering if it’s considered a good practice to restrict direct access to your view-files? Obviously they are going to contain a lot of php-code that relies on variables and what not passed to them from the controller, so the php-code could easily come up with an error if it’s directly accessed couldn’t it?
Bonus question: Why are the helpers, libraries, hooks etc. folders empty in the application folder?
Thanks for your time.
The main reason nobody bothers to restrict access to their view files is because they will either fatal error or show a useless page.
If people want to go to the effort of trying to work out your folder structure and file names, they will be rewarded with... absolutely nothing. You would have to write some really crazy code to make a view insecure.
If you REALLY want to secure them, go ahead.
At the top of your view, enter:
<?php if (!defined('BASEPATH')) exit('No direct script access allowed'); ?>
<h1>Whatever</h1>
I have never seen anyone restrict access to view files, but i dont see any reason why you wouldn't be able to do so. For better security you should really put your system and application folder below the web root and point the index.php back one directory to those folders. That way the possibility of someone directly accessing your files is slim to none.
As for why the folders are empty. The application folder is where you put YOUR code. The helper, libraries, and models folders in the system folder are filled with source code. The goal is to only put your code in application so when you upgrade to future versions of CodeIgniter your dont break any code or functionality you have implemented. You also can overload the codeigniter functions by doing what is says here...
http://codeigniter.com/user_guide/general/creating_libraries.html
and scroll down to "Extending Native Libraries"
user,
if you are on a shared host and they don't allow access to anything else than wwwroot folder, you can create a subfolder (name it "private") and write its .htaccess file to deny all requests to this subfolder. Then you can place the system and application folders of codeigniter in this subfolder and place your index.php folder in the regular location (changing the "system" and "application" variables inside index.php to correctly reflect the new paths) and that way all code is secure from direct access. :-)
edited:
About the folders question, its a scope thing. The helpers, libraries, hooks application folders are for application specific items. Maybe ones you custom create, or maybe ones downloaded from a third party. But the idea is that you have "system-wide" items and then you have "application-wide" items. Having application folders allows you to extend system-wide items to meet the specific application needs (see more # http://codeigniter.com/user_guide/general/creating_libraries.html). This doesn't make too much sense with one application, but if your installation has multiple applications, thats really where this comes in handy.
Not quite sure how to phrase this, but will do my best.
I have an application (written in PHP) that I want to install somewhere like this:
/app/build/1.0/
Now, I want to be able to set up subdomains, something like this:
http://sub1.mydomain.com
http://sub2.mydomain.com
etc ..
First, I want to put the least # files as possible in the subdomains (I am thinking just a config file), and point to the build folder for all php files.
However, in the case where the subdomain has some sort of customization, I would like to be able to actually place the customized file in the subdomain, and then the app would use that (in other words, app first looks for local file, if it exists use it, otherwise, use the default build folder files).
Last, if I release 1.1, I should simply be able to re-point the subdomains to the 1.1 folder.
I have a basic understanding of this and how I might achieve it, but what I am looking for is alternative ideas, or gotchas I may face (or anything else I may not have considered like scalability issues I may not see yet, or other things I may not be able to do if I go this route).
Bottom line question: Is this a good or bad idea, and why?
I'm assuming that the config file in each subdomain means there will be config differences for every site, so that you can't combine all of the uncustomized sites into one folder and simply have the subdomains point to it (in DNS).
I have set up sites such that the subdomains would have a single index.php file. The index.php file would define a bunch of config options and then call something equivalent to startApp(); Each site would have its include path set to include the application files. That can be done in the apache config or in the index.php file.
If you want to customize a site, then you would change the include path to point to the customized code, which you could keep in that sites folder if you want.
Honestly, I think the harder problem will be keeping all the customizations documented and updated. That's a totally different problem though.