In an ideal world, application developers would only have to build the functionality that the users want. Other specialized layers like the web server, the OS, the database, the programming language and the framework would take care of security. In practice developers of web based applications have to be aware of security implications with allmost every detail of the application they develop.
The most important risk you want to avoid is unauthorized access to OS level executables and functions that can breach system security. Php and its extensions offer many functions that allow access to these. Don't assume your system operator has taken sufficient precautions. You have to assume that if someone succeeds to have is self-written php code to be executed on your server, the worst will happen. Because of this the convenience offered by phpPeanuts to run your application and extend and override the framework behavior without having to register every class and skin you add requires some stringent security measures: class names, skin names, directoy names and property names that are derived from request data must be checked to be alphanumeric. The framework does this and if you use the designated methods these checks will be applied too. But if you occasionally bypass them, bad things can happen easily. So use (try)includeClass, include, require and eval functions only with hardcoded parameters unless you really know what you are doing and have checked and double checked everything.
Another risk for all applications is SQL injection. It may occur if data coming from request parameters is not quoted/escaped correctly. The methods of phpPeanuts for retrieving objects, for saving objects and objects for specifying queries are desinged to do so. If you "manually" compose queries or query templates, allways use , or on data before it is included in a SQL query.
If you use user authentication you may want to use secure http (https) to encrypt the communication between browser and web server. If you don't, passwords and cookies may be 'sniffed' when they traverse the network. The latter will allow third paties to hijack your users session and act as if they where the user that was authenticated. Furhermore packets may be sneaked in to make the sever do things the client never asked for or process data that was not sent by the client. If you use a web hosting account you can ask your internet hosting provider how to make pages and scripts for https. If you have your own server, see your web server documentation.
Do not think that if the communication between web server and browser is secure, your application is secure. Your user authorization may be vulnerable to automated trying out weak passwords for known user names, or try out many passwords by brute force. A good password policy is no luxury and your authentication system needs to protect from brute force attacks (the authenticaton plugin denies access to any login attempts made within 5 seconds from the last attempt, if you want a longer delay, you can set it on the authenticator in .
Then when you have secured your application against all this, one of your users may have loggend in and then click on a hyperlink to your site that has a script in one of its request parameters. If the application includes the value of the parameter in a pase, the script will run as if it was a part of your application, steal the cookies that are used for authentication and send them to some third party so that they can hijack the users session. You can do two things to prevent this, and it is advisable to do both: filter out the script from the request data by using (NOT the now depricated !), and encode all data that is included in pages or scripts that are sent to the browser by or . As of version 1.4.beta1 the framework is designed to do this. Do not use older versions of phpPeanuts for sites with authentication.
Last but not least the server itself can be hacked. Viruses, worms and spyware are often used by hackers to get in. On web hosting accounts using shared servers it is happens that all files set to be readable to everyone are readable from scripts running on other accounts (so that apache can read them). This includes the files written by PHP to store its session content. This content us used by the authentication plugin to store information by which it authenticates users after login. This way other hosting accounts that share the same session storage may be able to hijack your users authenticated sessions. If you have your database user name and password in such a file (which is the default with phpPeanuts), getting access to your database may also be easier then you think. If you have a folder where files can be uploaded, other accounts may be able to put a php file there, then make a request causing your account to execute it. It is not said that all this will happen, but you should not take for granted that it can't.
Notwithstanding our efforts this description may not be complete. Other risks may exist, or be invented as you read. Security is a different profession then software development, consider to consult a specialist of you need your application to be secure (warning, phpPeanuts was not screened by security specialists). |
