YII is a free open source web application development frame work written in php5. It has the extremely optimized performance and it is a perfect choice for any kind of projects. Its high and impressive performance while comparing with other PHP-based frameworks immediately drew very positive attention. Its popularity and adoption continues to grow at an ever increasing rate.

YII is the fastest PHP frame work best for creating large scale Web2.0 applications. YII can be used for developing any kind of web applications. It is especially suited for high traffic web applications like portals,forum, social media sites and so on. The name YII(pronounced as ‘yee’) is the abbreviation of “Yes It Is”. Obviously it is the answer for the questions like:

Is it fast? … Is it secure? … Is it professional? … >> Yes, it is!

Why YII?

YII has the features like MVC,DAO/ActiveRecord,caching, authentication and role-based access control, scaffolding, testing and so on. It is light weight and has powerful caching support. Security is a part of this frame work. It includes input validation, output filtering, SQL injection and Cross-site scripting prevention.

YII is much faster because it is using lazy loading technique. It does not enable a functionality until or unless that has been invoked for the first time. For example it does not create an object unless the object is called for the first time. Other frameworks suffer from the performance hit because they would enable a functionality no matter it is used or not during a request.

1. Performance.

YII has the extreme performance compared to other frame works. The YII team have generated a statistics for the performance of different frame works based on “request per second” which describes how many requests an application written in a framework can process per second. From the graph given below the RPS is for “request per second”. The higher number shows the higher performance level of the frame work. The performance is significantly high when we enable the PHP extension APC.

2. Security.

Security measures like Cross-site Scripting Prevention, Cross-site Request Forgery Prevention and Cookie Attack Prevention are enabled. Also YII includes client side and server side validation. We can just enable or disable the validation rule. It is not required to write separate validation rule for the inputs like other frameworks. YII has built-in authentication support. It also supports authorization via hierarchical role-based access control.

3. Best Caching features.

YII provides various cache components to store cached data in different media. While comparing to other frame works YII has an excellent caching system. YII supports memcache, APC, XCache and DB based page and segment caching.

4. Friendly with third-party code

YII is also designed to work with third party codes. You can use code from PEAR or Zend Framework in your YII application.

5. Easy to extend / customize

It is very easy to edit or customize the YII based applications, since it has a very simple code structure. You can also use different kinds of extensions and widgets as per the requirements.

YII is purely object oriented, architecturally clean and very simple to extend it. If you are not experienced with the PHP frame works and want to develop some simple applications, then maybe you should try an easier framework. I recommend to everyone who knows object oriented programming should pick up YII and try it once.

About the Author :

Prasobh Balakrishnan works as a Software Engineer in Bobcares. He joined Bobcares in may 2012. He loves programming and listening to music in his free time.

Often we are worried about our hosted websites. Its better to be proactive and make your hosting secure rather than wait for the intruder to make you realize that

1. Change your passwords regularly Keep strong passwords and never use the same password for different accounts. Changing the password will bring a bit of uncertainty in play which is ofcourse a better option.

I know you may find it a bit difficult to remember so many different passwords and that too by writing it down. So, it is better to use a password manager application software. Now a days, there are many softwares available such as Password Gorilla (uses Blowfish algorithm) , KeePass Password Safe, Oubliette, Password Safe, Revelation etc. Some of them can be used for Windows while others can we used for any OS (Linux,Free BSD)

2. Use Rkhunter or Chrootkit Rkhunter checks for rootkits in the server and reports them. Chrootkit checks for known signatures in the system binaries and reports if it finds anything suspicious.They check out for scripts that hackers can put into your server just for fun or otherwise serious implications. Keep checking their logs regularly to keep you updated.

3. Always keep checking whether your files and folders have got the correct permissions or not There are chances for hackers to upload some files if the permissions are 777. If you have any doubt about any of the permissions, report it immediately to your hosting provider.

4. Deleting the old files and folders which you are no longer using is also a good practice. Not only it clears up some disk space, it also gives less opportunities to hackers. Also, the number of files which you have to secure will be less.

5. Make sure that every software is updated As all of us know that Linux is a open source OS, hence periodically every software used in Linux distributions gets updated to remove the previous flaw. Make sure that every update is done to tighten the security.

6. Its always advisable to disable the feature “allow url fopen “ in PHP system functions as it provides the hackers the opportunity to put some php scripts.

7. Securing MYSQL should also be given high priority. Accessing of the MySQL database should not be allowed for any and everyone. Securing MYSQL can be done with the help of Access Control Lists and SSL-encrypted connections, for protecting the php MySQL web development. Its always preferable to enable SSL-encrypted connections.

8. Its advisable to use SSH and SFTP protocols instead of telnet or FTP. Telnet and FTP are considered to be insecure as they don’t use any encrypted protocols. In a hosting environment, its always preferable to use encrypted methods

9. Always take the backup of the websites as well as databases on a daily basis. Its preferable to keep the backups in different locations for security purpose as well as in case of server crash scenarios.

10. If you are using any content management softwares then be very particular about the guidelines which they have mentioned.

The above is a very rough outline of the Security measures, if you have any questions, we would be happy to talk to you!

About the Author :

Vivek Kumar works as a Software Engineer in Bobcares. He joined Bobcares in April 2011. He loves to watch movies in his free time.

Blog edited by :

Arundhati Rath works as a Software Engineer in Bobcares. She joined Bobcares in June 2011. She loves listening to music in her free time.

On May 3rd, a PHP-CGI vulnerability termed as “severe” by CloudLinux was published in US CERT web site.

The vulnerability causes any server running PHP as CGI to allow source code disclosure and arbitrary command execution using the account’s privileges. The quote from US CERT web site is below:

When PHP is used in a CGI-based setup (such as Apache’s mod_cgid), the php-cgi receives a processed query string parameter as command line arguments which allows command-line switches, such as -s, -d or -c to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution.

 While the primary vulnerability was reported for PHP-CGI executions, the CloudLinux note cautioned that this could be applicable to suPHP and mod_fcgid as well. But a post in suPHP mailing list says it is not affected by this vulnerability.

Response from Parallels

Parallels reacted with a 3 point resolution to this issue, as described in their KB entry on CVE-2012-1823.Important points are quoted below:

This is a Critical Vulnerability that affects software that contains PHP-CGI. PHP-FastCGI is not vulnerable to this exploit.
Parallels Plesk for Windows versions 10.4 and earlier are NOT affected.
Parallels Plesk for Linux versions 9.3 - 10.4 are NOT affected by the PHP-CGI remote code execution vulnerability due to use of the special cgi_wrapper script.
Parallels Plesk for Linux versions 8.6 and earlier are NOT affected due to use of mod_php only.
Parallels Plesk for Linux versions 9.0 - 9.2.3 might be vulnerable. Plesk team is working on an update.

1. It’s strongly recommended to update Plesk to the higher version that is not vulnerable.
2. CGI wrapper is the recommended way to workaround the issue, if Plesk update is not possible.
3. It is also possible to workaround the problem with .htaccess rules for each website.

Response from cPanel

A very reassuring post from cPanel says the customers who use EasyApache to compile their web servers are safe. cPanel though cautions that mod_cgi and mod_cgid are not recommended, and should ideally use suPHP. cPanel’s documentation says that suPHP is compiled using paranoid settings, which means that as long as you are using the latest PHP in a cPanel server running suPHP, you should be safe.

Response from CloudLinux

CloudLinux was one of the first to react to this situation, and have released a patch for those servers using PHP from CloudLinux repository. The patch is released in beta state and are awaiting a fully tested solution from RedHat. For the time being, the recommended solution is to upgrade PHP using the cloudlinux-updates-testing repo as quoted below from the CloudLinux blog post.

To deploy on CL5 (php53-5.3.3-5.el5.cloudlinux.1):
# yum update php53 –enablerepo=cloudlinux-updates-testing
To deploy on CL6 (php-5.3.3-3.el6_2.6.cloudlinux.1):
# yum update php –enablerepo=cloudlinux-updates-testing

To update PHP 5.1 on CL5 (php-5.1.6-32.el5.cloudlinux.1)
# yum update php –enablerepo=cloudlinux-updates-testing

So to summarize, if you have cPanel servers with the recommended web server settings you do not have anything to worry about. If you are using mod_cgi or mod_cgid, switch to suPHP, and you will be safe. If you are using Plesk products, upgrade to the latest release. If you have any questions, we would be happy to answer.

Visakh has been with Bobcares from May 2004, and has extensive experience in administering various control panels and operating systems used in web hosting industry. He is an avid reader, and loves topics on technology, humour and philosophy.

While discussing PHP permissions in the last blog, we concluded that SuPHP servers ideally needed PHP file permissions of just 600.

Out of many means to set the permission/ownership, the quickest is to set the permissions, using a script. You may set this script as a cron that runs daily or weekly, to take care of the the permissions. The script is now written for a server that has cPanel installed. Slight modifications to it, would make it work with other control panels, or even on servers that do not have any control panels.

The script also allows certain accounts to have custom PHP permissions, so that any custom application that needs specific permissions can be run, and such accounts would not be affected by the script.

The PHP permission script primarily does the following :

1. Changes the ownership of any PHP files(within public_html) under the ownership of nobody to the ownership of the user.

2. Changes permission of PHP files with 444 or 440 permission to 400.

3. Changes permission of all PHP files except those having 000 or 400 permissions to 600.

Steps to use this script :

1. Create /usr/local/customscripts folder

mkdir /usr/local/customscripts

2. Create the script file /usr/local/customscripts/php-perms.sh using your favorite editor.

vim /usr/local/customscripts/php-perms.sh

3. Give execute permission to the script

chmod -v 755 /usr/local/customscripts/php-perms.sh

Script given below can be used in cPanel servers which has suPHP enabled.

#!/bin/bash
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/X11R6/bin:/root/bin;
cd /usr/local/customscripts/;
for i in $(cut -d " " -f 2 /etc/trueuserdomains)
do
if [ ! -f /home/$i/customperm.txt ]
then
find /home/$i/public_html -type f -user nobody -group nobody -name *.php -exec chown -v “$i”:”$i” {} ;
find /home/$i/public_html -type f -perm 444 -o -perm 440 -name *.php -exec chmod -v 400 {} ;
find /home/$i/public_html -type f ! -perm 600 ! -perm 400 ! -perm 000 -name *.php -exec chmod -v 600 {} ;
fi
fi
done > php-perms-log.txt

You may add this as a cron job, as outlined in the following blog : cPanel adding cron job. This measure you take for PHP security would work only if you periodically keep setting the PHP permissions right. I would suggest to set is as a cron that runs every day, or say every 12 hours.

Script compatibility : Known issues

Some custom applications like the shopping cart Interspire has the practice of setting permissions to some uploaded files(images) to the permission set for its configuration file. Say you set 777 permission to the configuration file, it will give the permission of 777 to the uploaded images. If you set 600 permission to configuration file, it will set 600 permission to all uploaded images.

In such cases, or even other cases, where you need to have custom permissions for certain accounts, you may create a file by the name customperm.txt in the home directory of the account (like /home/cpanel_username/customperm.txt). The presence of this file will make sure that the script does not act upon PHP files within that account, and you can continue to have custom PHP permissions

Otherwise, the script works just fine in all of the production shared servers, and has helped in the overall manageability of PHP permissions and have added to the PHP file security!

About the Author :

Sherin George works as a Senior Software Engineer in Bobcares. He joined Bobcares back in September 2006. He loves reading technical blogs, and listens to music in his free time..

The article describes PHP file permissions, it’s effect on PHP security and general security on servers with suPHP.

PHP permission : The common misconception

PHP file permissions have always been in discussion among people who switch to suPHP. It is one of the most common questions you would find in every webhosting forum. But then the answer in most of those forums would be to set PHP permissions to 644. How secure is 644? - The answer would be “More than 777 anyhow”.

The source of this misconception is actually related to Apache’s ability to read files, so that it could be served by it. Even with suPHP, all non PHP files, that are to be served by Apache should have permissions of 644. Rather, others (apache/nobody) should have read access to the files, so that it could be served. With suPHP, the requirement for PHP permission hence goes to 600! Read the rest of this entry »

PHP open_basedir directive is used to limit the files that can be opened by PHP to a specific directory-tree. What does that mean? With the open_basedir directive, you can tell the PHP scripts on a domain, which folders they have access to. Once specified, the PHP scripts will not be able to access files outside those folders.

Read the rest of this entry »

Kohana is the PHP5 framework started as a fork of Codeigniter. When Codeigniter first appeared, it delighted the developers with its elegant user guide and simple and straightforward usage patterns. Codeigniter has only one limitation - that it doesn’t leverage the features of PHP5; creators of Codeigniter won’t regard this as a limitation because, it was meant to support both PHP4 and PHP5:)
Most of the clients who were forced to retain their old PHP4 server without upgrading to PHP5, but wanted to follow an organized structure for their projects welcomed Codeigniter. Read the rest of this entry »

The article explains suPHP and setting up suPHP on cPanel servers.

Constant Phishing/Spamming complaints can get extremely tiresome, and tracking down the source of the problem is not always easy. It wont be long before your IP addresses are listed on popular RBLs and your customers start complaining about mail delivery problems. To nip these problems in the bud, we have to look for better ways to track down the source of these problems. One way of better tracking processes on a cPanel server is switching to suPHP.

Read the rest of this entry »

PHP has a lot many frameworks and I have gone through many of them. One of the biggest difficulty that I found in some of them was the learning curve. Most of these frameworks use complex directory structures and difficult to remember naming conventions. Also, each one of them uses their own method for adding templates and db access. You don’t get the option to put in something that you are familiar with, like Smarty.

According to me, PHP is a powerful language for web programming, both with regard to speed as well as with the ease of use for web. And when you consider Java for web programming, servlets are a powerful concept. It indeed becomes handy when the design concepts of servlets and the speed and usability of PHP can be combined. This framework is an attempt on that path. (Download framework here.)

Read the rest of this entry »

PHP security is very important, as insecure php code can trigger in intrusion to your server. This article explains few such vulnerabilities, so that you can avoid them in your scripts. I will also explain methods to tweak PHP config files(php.ini) for maximum security.

Read the rest of this entry »