As a web developer I am using PHP and I know that I have to worry about security but when you use a framework, there is a lot-of code and design that you relay on but that you didn't code or design and for instance I am using CakePHP.
so in this case with frameworks how much should i worry about security ?
You should always continue respecting the basic principles of security :
don't trust the user
never trust the user
Which kinda means :
filter / validate everything that comes to your application
escape any output.
Using a framework doesn't change much about that, except that :
Output to the database often es some layer of the framework, which should deal with escaping
Frameworks often provide filtering / validation solutions ; use them ;-)
Frameworks often have some guidelines ; read them.
As a sidenote : you said this :
there is a lot-of code and design that
you relay on but that you didn't code
or design
Considering you are using a well-known framework that lots of people use, this code has probably been more tested/reviewed than any code you could write ;-)
That's an advantage of open-source, actually : you are not the only one responsible for the code, and lots of eyes have seen it -- which means lots of hands have enhanced it.
There are a lot of things to consider when dealing with security in an application. As Pascal said, it is a good idea to use a popular framework that has had a number of people looking at it.
I see a few areas of concern in regards to CakePHP.
The first issue is the end user. You should expect someone to do something foolish on every page you build. Some examples of this are:
A person clicking the submit button rapidly over and over. This may skew or mess up your system in a way if you're not careful. The solution for this is not based on the framework, but rather your coding methodology and testing.
SQL Injection and other bad things. Any field on a page can be potentially abused, therefore every form element must be sanitized. CakePHP has simple methods to take care of these security issues. http://book.cakephp.org/view/153/Data-Sanitization
Clean URL's are very important. You should never design a system that allows a user to access integer primary keys directly. For instance, if you have a site that has /show_user/2098 then someone can simply type in show_user/2097 to see someone else's account. CakePHP allows you to incorporate slugs or UUID's quite easily, to prevent this from happening.
Second, you must be concerned with attacks dealing with the code and permissions itself. For example:
Never use eval() or system() in your code from data that may come from the end user. There have been applications in the past written in perl that have been hijacked because of this issue.
The folder structure and permissions is important in regards to security. Users should never have access to get into a writable directory. With CakePHP the folder structure is designed so that you can point apache directly to app/webroot. This means the tmp directory is outside of the apache path, making the system a bit more secure.
Third, you should be concerned with the protection of your administration pages and who has permissions to access what.
CakePHP has an Auth and an Acl component that allows you to choose what users get access to which pages. This makes use of custom Cake Sessions which can be stored in a database, by using PHP or written to the file system.
I would suggest reading up on some of the important components and being sure you set them up properly, to ensue you have built an application without security flaws. Take a look at some of these elements as you research further: http://book.cakephp.org/view/170/Core-Components
I suggest you check out ESAPI: http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=PHP
It is not a framework per se, but does contain a lot of tools for the problems Pascal mentions.
Related
Here's something I've thought about for a while.
I am creating an application where's my users will upload their own custom themes, which means that there's going to be a good opportunity for anyone with basic PHP/XSS/whatever skills to cause a lot of headache.
I would like to run any uploaded files in a sort-of sandboxed, closed environment that only has access to the stuff (variables) that I want and nothing else.
Would this be good practice and how would it be done?
To allow arbitrary html/javascript safely then each user must have its own subdomain. If each user has their own subdomain then a user's JavaScript will be restricted their own sandbox because of the Same Origin Policy. If you only want to allow "safe html" then htmlpurifer is an option, and then you can use 1 domain.
Allowing custom PHP is a bit more hazardous. "Shared hosting" providers rely upon suPHP which forces the php script to run as a specific user. This would require every user to have their own account on your system. This method of defense has been around for a while. It isn't perfect but it does the trick.
Another possible solution for custom themes is to use a templating engine, which can prevent templates from getting full access to PHP. SOme popular frameworks for this:
smarty, it doesn't have the best secuirty track record, but you keep it up to date you probably won't have a problem. It needs to be configured to disallow native php.
twig is a relatively new engine from the makers of Symfony Framework. This means it has a decent developer base and since it ships with Symfony, it's also been tested in the wild. Twig does not allow any PHP functions to be called, unless you specifically create a twig function/filter for them.
As you don't want to grant your users access to PHP, you should use a template engine that supports sandboxing. Twig is a prominent example here.
global scope will always be accessible.
but object oriented concept provide a lot. what you can't do is to hide global stuff. what you can do is not make it visible in the first place.
but executing unreviewed 3rd party code is a tricky thing. i would recommend some sort of process isolation here if possible. which means you open a process using popen or something, in combination with suphp you can make a restricted linux user. that is very well possible and secure with the correct security measures in place.
a good approach to run the code within the same program is to use the templating pattern. its a bit unpractical for classes because whole files get loaded that can inject hazardous code. but you can create custom functions in php from code. the code does not get executed unless the function is called. you can also extend a class to a variable name, which is then user supplied code. however this is almost unpossible to make safe.
when it comes to html code , it is way easier. there are good html tidy is a good start. there are good solutions to allow only speical tags.
javascript can be "secured" in a way that old facebook fbml applications did. which includes server side rewrites, dynamic variable names etc its quite complicated.
in my opinion the best way to allow external customizations is to allow external stylesheets. just load them from an external origin and there is not really a security concern.
edit: of course you can parse any code and limit it to certain statements or deny certain statements, but this is very tricky and for php a very heavy constraint. its probably better to switch to some higher level algorithmic languages or go client side with javascript.
What you want to do is really risky. You should never allow your users to upload PHP files. That's why you don't find many PHP fiddlers around the net (though now there's some).
Also JS is dangerous in some indirect ways and pretty much nobody allows you to upload it (with the notable exception of Tumblr).
What you should do is adopt some kind of templating engine, and sanitize the templates the users upload, to remove scripts.
Since security is an issue, try to check security advisories like Secunia when choosing the templating engine.
This question can be applied to any programming language, but as I am thinking of PHP, I will phrase it accordingly...
I'm wondering if it is considered bad design/architecture if a web application uses action parameters, versus seperate files for each action.
For example:
/index.php?action=edit
Versus
/edit.php or /index/edit.php
I know mod_rewrite can translate a pretty-url to a parametrized url, but I try to avoid uneeded complexity when not necessary.
Thanks.
Quite often, for big applications, (especially with Frameworks, such as symfony, Zend Framework, ...) we tend to use one entry point : index.php.
That entry point will receive some informations (like your action parameter), that will allow it to route the request to the correct controller (or any equivalent you might have).
So, to make things short : no, using action parameters is not bad design / architecture.
Of course, this depends on the kind of application -- but, generally speaking, have a unique entry-point is quite a good idea.
Well I don't think it is a bad design - of course there is other possibilities - but overall it is about your in-house agreements between the programmers how you do it. As much as you can you should split the PHP and HTML code to make the development easier further on.
I prefer the MVC-coding style, which splits the PHP and HTML from each other as much as you "want it to".
Hope this is helpful :)
I would call both your examples at least outdated or short of best practice.
/index.php?action=edit
Doesn't look good and is therefore not user friendly and isn't SE friendly either.
/edit.php
Means that there is indeed a single file for each action which clearly is bad practice in the 21st century where we have great MVC frameworks which enable us to get rid of this clutter and keep the concerns separated.
A good URL looks for example like that:
mysite.com/user/profile/edit
meaning where in the user module, the user-profile controller and the edit action.
There is nothing actually bad in either, both can be used all right
Separate files considered to be better for the small application, to avoid unnecessary complexity as you said.
Action way is considered better to serve complex applications featuring single entry-point working as a boot-strap, initializing all the site features first and then calling appropriate module.
I just have to warn you against using such action in silly way, doing include $_GET['action'] in the middle of main 'design' file. it's both insecure and unreliable.
It depends on your requirements and scale.
Using separate files is ok. However, you will probably find yourself copying code and not properly reusing code and techniques. It's easier to do this with small, ad hoc applications, but could very well turn into spaghetti code or a jungle nest over time.
If you use a single point of entry (class loading with url handlers), you do have to learn how that works (CodeIgniter and ExpressionEngine are good MVC systems to use if you're not real good at it yet), but it's more consistent in coding practice, and scales better than a bunch of separate pages or a switch() statement you pass everything through.
It's not a panacea, either way, but most professional operations use something like an entry point with a class loading system (such as MVC).
About using mod_rewrite: mod_rewrite was not created and should not be used as part of your PHP architecture.
About having one file per logical element. This is a very good and practical way of separating logical units in your app. It way better than creating huge files with a lot of mixed logic inside, which will become unmaintainable as the app grows. This has no contradiction on having one point of entry and an MVC architecture.
Having action parameters is the most normal approach for CRUD controllers for example where makes a lot of sense to group actions to a common controller
// blog controller
-> create blog entry
-> edit
-> view
-> delete
-> list ( this is a very common addition to CRUD
all this have a common architecture in the sense that almost all accept an id and do related thing.
If you are talking strictly about GET parameters than you'll see that creating medium/large application where you direct everything from a file and the only thing changing is the get parameters will outgrow you very fast. Computer architecture is like real architecture, try to split thing in small, simple (maybe reusable) units.
I am building a site that requires a lot of MySQL inserts and lookups from different tables in a (hopefully) secure part of the site. I want to use an abstraction layer for the whole process. Should I use a PHP framework (like Zend or CakePHP) for this, or just use a simple library (like Crystal or Doctrine)?
I would also like to make sure that the DB inserts are done in a relatively secure part of the site (though not SSL). Currently, I am using the method outlined here (MD5 encryption and random challenge string), but maybe some of the frameworks come with similar functionality that would simplify the process?
What I'm trying to implement: a table of forms filled out with DB values. If you change a value or add a new row, pressing "save" will update or insert DB rows. I'm sure this has been done before, so I wouldn't want to reinvent the wheel.
Most PHP backends have secure access to a private database. Normally, there's little difficulty to keeping the database secure, mostly by not making it reachable directly. That way the security of access depends on the inability for anyone to tamper with the PHP code, and not any software security scheme.
I would recomend Symfony Framework for this. There is a great online tutorial on this at Practical Symfony.The Framework's Form class handles most of the security for you. It also has a nice login plugin to make the application secure.
Unless by Data Abstraction you mean an implementation of a Data Access Patterns like ActiveRecord or Table Data Gateway or something ORMish (in both cases you should update your question accordingly then), you don't need a framework, because PHP has a DB abstraction layer with PDO.
It sounds like you are really asking two different questions. One being should I use a framework (Zend, Symfony, Cake, etc) for the development of a website? The other being whether or not to use something along the lines of an ORM (Doctrine, Propel, etc)?
The answer to the first one is a resounding "yes". Frameworks are designed to keep you from having to reinvent the wheel for common/basic functionality. The time you spend learning how to (correctly) use a framework will payoff greatly in the long run. You'll eventually be much more productive that "rolling your own". Not to mention you'll gain a community of people who have likely been through similar situations and overcome issues similar to what you will face (that in and of itself could be the best reason to use a framework). I'm not going to suggest a particular framework since they all have strengths and weaknesses and is another topic in and of itself (however, I do use and prefer Zend Framework but don't let that influence your decision).
Concerning whether or not to use an ORM is a slightly more difficult question. I've recently began to work with them more and in general I would recommend them but it all boils down to using the right tool for the right job. They solve some specific problems very well, others not so much. However, since you specifically mention security I'll quickly address that. I don't think that a ORM inherently "increases security", however it can force you into making better decisions. That said, bad coding and bad coding practices will result in security issues no matter what technology/framework you are using.
Hope that helps!
Right now I'm learning about the CakePHP framework, and I just wanted to know what makes CakePHP secure. How secure are its components like for example how secure is the authentication component. Also, what can we do as developers to increase the security of our CakePHP base web application?
Also do you guys recommend any books or sites to learn more about CakePHP security?
Hope to hear from you guys soon.
Thanks
Leo: Some sites don't need high levels
of security and they can give a
performance hit. Others must be
inviolable.
Sorry Leo, but i disagree. Every site you build, you do so with the utmost care of security in mind. Regardless of what type of site it is. Suppose for example you've built this very tight superduper hackersafe site. You host it on a shared server, and guess what.. Someone got access to your safe site via a hole in your less safe site. Or even the entire server.
I know, its a doom theory but i believe stuff like this happens on a daily bases.
Cake follows best practices in many areas, and has pretty secure tools built-in comes with infrastructure that already has many typical areas of webapp security covered to some degree. You won't need to worry much about SQL injection for example, since Cake's database abstraction escapes all input. Where it doesn't, the manual warns you appropriately:
updateAll(array $fields, array $conditions)
! The $fields array accepts SQL expressions. Literal values should be quoted manually.
Using the SecurityComponent you get automatic form spoofing protection.
Data validation is a big integrated part of models.
The AuthComponent hashes and salts passwords properly, though not necessarily in the most secure manner possible.
There's a handy h() shortcut for htmlentities that you should use to escape output to avoid XSS problems.
Et cetera perge perge...
You will still have to use all the components correctly though and be careful not to open any "custom" holes. Cake is only a toolbox, it's still perfectly possible to build a horrendously insecure application using it. You can still shoot yourself in the foot, no matter how good the gun. The default Cake structure is only a starting point. It's not the end-all-be-all in terms of security; think for yourself. The link provided by John is indeed a good starting point.
The CakePHP framework has been around for quite some time (since 2005) and is open source software. This means its code is available for review by any developer, or non-developer, who wishes to do so. Both the CakePHP community and security communities have had ample time to review the code base and find/correct potential security issues. That doesn't mean that the software is perfect but with CakePHP being so popular you can bet it's been reviewed quite thoroughly and if there are any flaws in it they are deep and very difficult to find/identify.
But keep in mind, just because the code in the framework is secure doesn't mean using it makes your code secure. You still need to follow secure coding practices because your code base can be vulnerable regardless of the security level of the framework you use.
Cake security is pretty good, but everything has holes. For an ultra secure site, I'd be researching known security holes and blunders and testing the site against those cases. It simply isn't enough to rely on someone else's statement of a degree of security.
Some sites don't need high levels of security and they can give a performance hit. Others must be inviolable.
All said, I'm impressed with Cake's inbuilt security and haven't had to modify it yet.
I'm going to write a framework for my web projects in PHP.
Please don't tell me about considering to use some existing framework (Cake, CodeIgniter, Symfony, etc.) - I have already had a look at them and decided to write one for myself.
The framework itself will mainly consist of a module system, a database handler and a template parser. (Many other things too, of course)
With module system I mean that every module has exactly one PHP file and one or more templates associated with it.
An example module would be modules/login.php that uses templates/login.tpl for its design.
These days everyone(?) is talking about the MVC (Model View Controller) concept and most of the existing frameworks use it, too.
So my questions are the following:
Is MVC really effective for a personal framework?
Would it be a bad idea to use a module system?
Did you ever write a framework for yourself? What are your experiences?
Is MVC really effective for a personal framework?
Yes, it can be. Although, it might be a little overkill (which, is not necessarily a bad thing if you are trying to learn)
Would it be a bad idea to use a module system?
This is never a bad idea.
Did you ever write a framework for yourself? What are your experiences?
I wrote a common security framework for my group's PHP applications when I was an intern. I learned alot, but the project as a whole might have benefited more from a pre-built solution.
Of course, I wouldn't have learned as much if I just installed a pre-built solution. So you always have to take that into account, especially for personal projects. Sometimes re-inventing the wheel is the only way you will learn something well.
Is MVC really effective for a personal framework?
What MVC means anymore, due to its vague interpretation, is business logic, presentation, and input handling. So, unless you aim to design an application that does not involve any three of those, MVC is, in its vague sense, very suitable.
Often it can be more formal than you desire, however, as it demands physical separation of ideas into different code files. Quick and dirty tasks or rapid prototyping might be more quickly setup if the formalities are avoided.
In the long term, what MVC asks for is beneficial to the sustainability of the application in ways of maintenance and modification or addition. You will not want to miss this. Not all frameworks encourage the right practices, though. I am not surprised that you find the various implementations you've tried insufficient. My personal favourite is Agavi. To me and others, in a world of PHP frameworks that do not feel right, Agavi emerges to do the right things. Agavi is worth the shot.
Would it be a bad idea to use a module system?
MVC asks you to separate components of business logic, presentation, and input handling, but it does not suggest how to layout the files. I presume this is the challenge you are addressing with a module system. To answer your question: modules serve identically to sub-directories. If the items are few, its probably more hassle to bother with subdirectories even if the files could logically be separated into them. When the number of items grow large, its now cumbersome to locate them all and sub-directories become a better option.
Frameworks will tack on functionality that allows you to deal with modules as their own configurable entity. The same functionality could just as well exist without modules, perhaps in a more cumbersome manor. Nonetheless, do not consider modules primarily as a system. Systems are so wonderfully vague that you can adapt them to whatever setup you find suitable.
Did you ever write a framework for yourself? What are your experiences?
Yes I have wrote several frameworks with various approaches to solving the issues of web applications. Every such framework I wrote became nothing but a vital learning curve. In each framework I made I discovered more and more the issues with building software. After failing to create anything interesting, I still gained because when asked to make a program I could fully do so with justice.
I recommend you continue if this is the sort of learning experience you want. Otherwise, give Agavi a shot. If that too fails, ensure that you have a clear and detailed specification of what your framework will do. The easiest way to barge into making software, work really hard, and accomplish nothing is to not decide before-hand what exactly your software will do. Every time I ran into making code the only thing in my mind was I will do it right. What happened was a different story: oh, well I need to make a routing system as that seems logical; hmm, okay, now I need a good templating system; alright, now time for the database abstraction; but gee, what a lot of thinking; I should look to the same system from software XXY for inspiration. Therein is the common cry that pleads to use existing software first.
The reason I thought I could do it right was not because all the nuts and bolts of the framework felt wrong. In fact, I knew nothing about how right or wrong they were because I never worked with them. What I did work with was the enamel, and it felt wonky. The quickest way to derive your own framework is really to steal the nuts and bolts from another and design your own enamel. That is what you see when building an application and frankly is the only part that matters. Everything else is a waste of your time in boilerplate. For learning how to build software, however, its not a waste of time.
If you have any other questions, please ask. I am happy to answer with my own experience.
I am also actually writing a php framework with a friend of mine. I absolutely can understand what you do.
I thing what you are doing is near mvc. You have the templates as views. And the modules as controller. So I think that is ok. The only thing you need is the model. That would be some kind of active records.
In my framework there are simular concepts, except we are writing our own active records engine at the moment. I think what you do isn't bad. But it's hard to say without seeing code.
I see only one problem you have to solve. A framework should be perfectly integrated. It is always a complicated to make your module look nice integrated without always have to think of module while you are coding application.
Is MVC really effective for a personal framework?
Would it be a bad idea to use a module system?
Yes it is. But MVC is such a loosy-goosy design pattern that you can draw the line between model, view, and controller anywhere you want. To me, the most important parts are the model and the view. I simply have pages, php modules, that generate html by filling in a template from a database. The pages are the view and the database is the model. Any common application-specific code can be factored out into "controllers". An example might be a common, sophisticated query that multiple pages must use to render data.
Other than that I have utilities for safe database access, simple templating, and other stuff.
Did you ever write a framework for yourself? What are your experiences?
Yes. I'm very glad I did. I can keep it simple. I know intimately how it works. I'm not dependent on anyone but myself. I can keep it simple yet useful.
Some pointers (0x912abe25...):
Every abstraction comes with a cost.
Don't get to fancy. You might regret not keeping it simple. Add just the right amount of abstraction. You may find you over-abstracted and something that should be simple became excessively complex. I know I've made this mistake. Remember You-aint-gonna-need-it.
Scope your variables well
Don't load your pages by doing
include_once('...page file ...');
where it's expected that page file will have a bunch of inline php to execute looking up different global variables. You lose all sense of scope. This can get nasty if you load your page file from inside a function:
function processCredentials()
{
if (credentialsFail)
{
include_once('loginpage.php');
}
}
Additionally, when it comes to scoping, treat anything plugged into templates as variables with scope. Be careful if you fill in templates from something outside the page file associated with that template (like a master index.php or something). When you do this it's not clear exactly what's filled in for you and what you are required to plug into the template.
Don't over-model your database with OO.
For simple access to the database, create useful abstractions. This could be something as simple as fetching a row into an object by a primary index.
For more complex queries, don't shy away from SQL. Use simple abstractions to guarantee sanitization and validation of your inputs. Don't get too crazy with abstracting away the database. KISS.
I would say that MVC makes more sense to me, since it feels better, but the only practical difference is that your login.php would contain both the model (data structure definitions) and the controller (code for page actions). You could add one file to the module, e.g. class.login.php and use __autoload() for that, which would essentially implement an MVC structure.
I have refactored a big PHP project to make it more MVC compliant.
I found especially usefull to create a DAO layer to centralize all database accesses. I created a daoFactory function, which creates the DAO and injects the database handle into it (also the logger, I used log4php, got injected).
For the DAO, i used a lot the functionalities of the database (mysql), like stored procedure and triggers. I completly agree with Doug T. about avoid over-abstraction, especially for database access : if you use the DB properly (prepared statements, etc.) you don't need any ORM and your code will be much faster. But of course you need to learn mysql (or postgress) and you become dependant on it (especially if you use a lot of stored procedure, like I tend to do).
I am currently refactoring a step further, using the Slim php framework and moving toward a restfull api : in this case there is no view anymore because everything is outputted as json. But I still use smarty because its caching works well and I know it.
Writing a framework could be a rewarding experience. The important thing to consider is that you do not write a framework for its own sake. The reason one writes a framework is to make development easy.
Since it is a personal framework you should think in terms of how it could help you develop with less hassle.
I do not think a template system is a good idea. Think of it - what is the major benefit of using a template system? The answer is that it helps teams with different skill sets jointly develop an application. In other words, some members of the team can work on the user interface and they do not need to be PHP coders. Now, a personal framework will most likely be used by a single person and the benefit of template system becomes irrelevant.
All in all, you should look at your own coding habits and methods and discover tasks that take most of your time on a typical project. Then you should ask yourself how you can automate those tasks to require less time and effort. By implementing those automation mechanisms you will have to stick to some sort of conventions (similar to an API). The sum of the helper mechanisms and the conventions will be your personal framework.
Good luck.
MVC doesn't work
you don't want to be constrained in the structure of your "modules"; also, keep templates close to the code (the templates directory is a bad idea)
no
re 1.: see Allen Holub's Holub on Patterns. briefly: MVC basically requires you to give up object oriented principles.
Tell Don't Ask is a catchy name for a mental trick that helps you keep the data and code that acts on it together. Views cause the Model to degrade into a heap of getters and setters, with few if any meaningful operations defined on them. Code that naturally belongs in the Model is then in practice spread among Controllers and Views(!), producing the unhealthy Distant Action and tight coupling.
Model objects should display themselves, possibly using some form of Dependency Injection:
interface Display
{
function display($t, array $args);
}
class SomePartOfModel
...
{
function output(Display $d)
{
$d->display('specific.tpl', array(
'foo' => $this->whatever,
...
));
}
}
OTOH, in practice I find most web applications call for a different architectural pattern, where the Model is replaced with Services. An active database, normalized schema and application specific views go a long way: you keep the data and code that acts on it together, and the declarative nature makes it much shorter than what you could do in PHP.
Ok, so SQL is a terribly verbose language. What prevents you from generating it from some concise DSL? Mind you, I don't necessarily suggest using an ORM. In fact, quite the opposite. Without Model, there's little use for an ORM anyway. You might want to use something to build queries, though those should be very simple, perhaps to the point of obviating such a tool...
First, keep the interface your database exposes to the application as comfortable for the application as possible. For example, hide complex queries behind views. Expose update-specific interfaces where required.
Most web applications are not only the owners of their respective underlying databases, they're their only consumers. Despite this fact, most web applications access their data through awkward interfaces: either a normalized schema, bare-bones, or a denormalized schema that turned out to make one operation easier at the price of severe discomfort elsewhere (various csv-style columns etc). That's a bit sad, and needlessly so.
re 2.: it's certainly good to have a unified structure. what you don't want to do is to lock yourself into a situation where a module cannot use more than one file.
templates should be kept close to code that uses them for the same reason that code that works together should be kept together. templates are a form of code, the V in MVC. you'll want fine-grained templates to allow (re)use. there's no reason the presentation layer shouldn't be as DRY as other parts of code.