1. Redirect to a secure https connection

If you want to redirect your entire site to a secure https connection, use the following:

1. RewriteEngine On
2. RewriteCond %{HTTPS} !on
3. RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

2. Block script execution

You can stop scripts in certain languages from running with this:

1. Options -ExecCGI
2. AddHandler cgi-script .pl .py .php .jsp. htm .shtml .sh .asp .cgi
   

3.  Restrict file upload limits for PHP

You can restrict the maximum file size for uploading in PHP, as well as the maximum execution time. Just add this:

Building traffic to your website is not an easy task. “If you build it, they will come” concepts work only for movies and it does not work with your website. A well designed website is just the first step in your internet business venture. Driving traffic to your website takes Knowledge, proper planning, time and great effort. I write this post believing that these tips will help you reach the right people to achieve online business success.

It is imperative to determine your online business objectives or goals before you plan the online strategy and definitely before you even write the first line of code for your website. Know your objectives and build your website around them, it will ensure satisfaction at the end of the day.

Presenting your website message carefully is yet another important factor for any successful website. The visitors to your website need to know and understand your message instantly from the very first page that is your home page. If not they will bounce back to another website most probably your competitor. Keep an eye on your website load time. The visitor to your site may not have time to wait till it loads the first page of your website. Imagine if your home page loads very slowly and the face of an impatient visitor. A good visitor will definitely tell 100 friends about your website, while an unsatisfied visitor will tell 1000 people about your website.

Use your competitor site to the maximum and take advantage of it. They might have brainstormed 1000 ideas and stands strong as a competitor. Learn what they are doing, what do you feel your website lack, ask yourself. Visit your niche related sites and the sites that are listed on hot sites pages. In the coming posts I will discuss about studying the competitor website in a Search Engine point of view. It is the key techniques we do to make our clients stand strong in any competition. Look at the design of your competitor website and learn the do’s and don’ts of the niche website marketing. See how the information is organized, feature provided, color, background etc.

Realize the potential of your domain name. Domain name plays an important role in internet marketing. Your internet domain is your exclusive web address, which you can purchase through several domain registrars.The domain name itself can add traffic to your website. There are certain points you need to remember when buying a domain name. We will discuss that in the coming posts. The above given are some quick tips you need to revisit when you plan to create your online identity.

1. Unvalidated Parameters

Most importantly, turn off register_globals. This configuration setting defaults to off in PHP 4.2.0 and later. Access values from URLs, forms, and cookies through the superglobal arrays $_GET, $_POST, and $_COOKIE.

Before you use values from the superglobal arrays, validate them to make sure they don’t contain unexpected input. If you know what type of value you are expecting, make sure what you’ve got conforms to an expected format. For example, if you’re expecting a US ZIP Code, make sure your value is either five digits or five digits, a hyphen, and four more digits (ZIP+4). Often, regular expressions are the easiest way to validate data:

if (preg_match('/^\d{5}(-\d{4})?$/',$_GET['zip'])) {
    $zip = $_GET['zip'];
} else {
    die('Invalid ZIP Code format.');
}

If you’re expecting to receive data in a cookie or a hidden form field that you’ve previously sent to a client, make sure it hasn’t been tampered with by sending a hash of the data and a secret word along with the data. Put the hash in a hidden form field (or in the cookie) along with the data. When you receive the data and the hash, re-hash the data and make sure the new hash matches the old one:

// sending the cookie
$secret_word = 'gargamel';
$id = 123745323;
$hash = md5($secret_word.$id);
setcookie('id',$id.'-'.$hash);

// receiving and verifying the cookie
list($cookie_id,$cookie_hash) = explode('-',$_COOKIE['id']);
if (md5($secret_word.$cookie_id) == $cookie_hash) {
    $id = $cookie_id;
} else {
    die('Invalid cookie.');
}

If a user has changed the ID value in the cookie, the hashes won’t match. The success of this method obviously depends on keeping $secret_word secret, so put it in a file that can’t be read by just anybody and change it periodically. (But remember, when you change it, old hashes that might be lying around in cookies will no longer be valid.)

See Also:

• PHP Manual: Using Register Globals
• PHP Cookbook: Recipe 9.7 (”Securing PHP’s Form Processing”), Recipe 14.3 (”Verifying Data with Hashes”)

2. Broken Access Control

Instead of rolling your own access control solution, use PEAR modules. Auth does cookie-based authentication for you and Auth_HTTP does browser-based authentication.

See Also:

• PEAR Packages: Auth, Auth_HTTP.

3. Broken Account and Session Management

Use PHP’s built-in session management functions for secure, standardized session management. However, be careful how your server is configured to store session information. For example, if session contents are stored as world-readable files in /tmp, then any user that logs into the server can see the contents of all the sessions. Store the sessions in a database or in a part of the file system that only trusted users can access.

To prevent network sniffers from scooping up session IDs, session-specific traffic should be sent over SSL. You don’t need to do anything special to PHP when you’re using an SSL connection, but you do need to specially configure your webserver.

See Also:

• PHP Manual: Session handling functions
• PHP Cookbook: Recipe 8.5 (”Using Session Tracking”), Recipe 8.6 (”Storing Sessions in a Database”)

4. Cross-Site Scripting (XSS) Flaws

Never display any information coming from outside your program without filtering it first. Filter variables before including them in hidden form fields, in query strings, or just plain page output.

PHP gives you plenty of tools to filter untrusted data:

• htmlspecialchars() turns & > " < into their HTML-entity equivalents and can also convert single quotes by passing ENT_QUOTES as a second argument.
• strtr() filters any characters you’d like. Pass strtr() an array of characters and their replacements. To change ( and ) into their entity equivalents, which is recommended to prevent XSS attacks, do:
  $safer = strtr($untrusted, array('(' => '(', ')' => ')'));
• strip_tags() removes HTML and PHP tags from a string.
• utf8_decode() converts the ISO-8859-1 characters in a string encoded with the Unicode UTF-8 encoding to single-byte ASCII characters. Sometimes cross-site scripting attackers attempt to hide their attacks in Unicode encoding. You can use utf8_decode() to peel off that encoding.

See Also:

• PHP Manual: htmlspecialchars(), strtr(), strip_tags(), utf8_decode()
• PHP Cookbook: Recipe 8.8 (”Building a GET Query String”), Recipe 9.8 (”Escaping Control Characters from User Data”)

5. Buffer Overflows

You can’t allocate memory at runtime in PHP and their are no pointers like in C so your PHP code, however sloppy it may be, won’t have any buffer overflows. What you do have to watch out for, however, are buffer overflows in PHP itself (and its extensions.) Subscribe to the php-announce mailing list to keep abreast of patches and new releases.

See Also:

• PHP Mailing Lists: http://www.php.net/mailing-lists.php

6. Command Injection Flaws

Cross-site scripting flaws happen when you display unfiltered, unescaped malicious content to a user’s browser. Command injection flaws happen when you pass unfiltered, unescaped malicious commands to an external process or database. To prevent command injection flaws, in addition to validating input, always escape user input before passing it to an external process or database.

If you’re passing user input to a shell (via a command like exec(), system(), or the backtick operator), first, ask yourself if you really need to. Most file operations can be performed with native PHP functions. If you absolutely, positively need to run an external program whose name or arguments come from untrusted input, escape program names with escapeshellcmd() and arguments with escapeshellarg().

Before executing an external program or opening an external file, you should also canonicalize its pathname with realpath(). This expands all symbolic links, translates . (current directory) .. (parent directory), and removes duplicate directory separators. Once a pathname is canonicalized you can test it to make sure it meets certain criteria, like being beneath the web server document root or in a user’s home directory.

If you’re passing user input to a SQL query, escape the input with addslashes() before putting it into the query. If you’re using MySQL, escape strings with mysql_real_escape_string() (or mysql_escape_string() for PHP versions before 4.3.0). If you’re using the PEAR DB database abstraction layer, you can use the DB::quote() method or use a query placeholder like ?, which automatically escapes the value that replaces the placeholder.

See Also:

• PHP Manual: escapeshellcmd(), escapeshellarg(), realpath(), addslashes(), mysql_real_escape_string(), mysql_escape_string()
• PEAR Package: DB, DB Documentation
• PHP Cookbook: Recipe 18.20 (”Escaping Shell Metacharacters”), Recipe 10.9 (”Escaping Quotes”)

7. Error Handling Problems

If users (and attackers) can see the raw error messages returned from PHP, your database, or external programs, they can make educated guesses about how your system is organized and what software you use. These educated guesses make it easier for attackers to break into your system. Error messages shouldn’t contain any descriptive system information. Tell PHP to put error messages in your server’s error log instead of displaying them to a user with these configuration directives:

log_errors = On
display_errors = Off

See Also:

• PHP Manual: Error Handling and Logging Functions
• PHP Cookbook: Recipe 8.14 (”Hiding Error Messages from Users”)

8. Insecure Use of Cryptography

The mcrypt extension provides a standardized interface to many popular cryptographic algorithms. Use mcrypt instead of rolling your own encryption scheme. Also, be careful about where (if anywhere) you store encryption keys. The strongest algorithm in the world is pointless if an attacker can easily obtain a key for decryption. If you need to store keys at all, store them apart from encrypted data. Better yet, don’t store the keys and prompt users to enter them when something needs to be decrypted. (Of course, if you’re prompting a user over the web for sensitive information like an encryption key, that prompt and the user’s reply should be passed over SSL.)

See Also:

• PHP Manual: Mcrypt Encryption Functions
• PHP Cookbook: Recipe 14.7 (”Encrypting and Decrypting Data”)

9. Remote Administration Flaws

When possible, run remote administration tools over an SSL connection to prevent sniffing of passwords and content. If you’ve installed third-party software that has a remote administration component, change the default administrative user names and passwords. Change the default administrative URL as well, if possible. Running administrative tools on a different web server than the public web server that the administrative tool administrates can be a good idea as well.

10. Web and Application Server Misconfiguration

Keep on top of PHP patches and security problems by subscribing to the php-announce mailing list. Stay away from the automatic PHP source display handler (AddType application/x-httpd-php-source .phps), since it lets attackers look at your code. Of the two sample php.ini files distributed with PHP ( php.ini-dist and php.ini-recommended), use php.ini-recommended as a base for your site configuration.

For a while now webmasters have fretted over why all of the pages of their website are not indexed. As usual there doesn’t seem to be any definite answer. But some things are definite, if not automatic, and some things seem like pretty darn good guesses.

PageRank

It depends a lot on PageRank. The higher your PageRank the more pages that will be indexed. PageRank isn’t a blanket number for all your pages. Each page has its own PageRank. A high PageRank gives the Googlebot more of a reason to return. Matt Cutts confirms, too, that a higher PageRank means a deeper crawl.

Links

Give the Googlebot something to follow. Links (especially deep links) from a high PageRank site are golden as the trust is already established.

Internal links can help, too. Link to important pages from your homepage. On content pages link to relevant content on other pages.

Sitemap

A lot of buzz around this one. Some report that a clear, well-structured Sitemap helped get all of their pages indexed. Google’s Webmaster guidelines recommends submitting a Sitemap file, too:

· Tell us all about your pages by submitting a Sitemap file; help us learn which pages are most important to you and how often those pages change.

That page has other advice for improving crawlability, like fixing violations and validating robots.txt.

Some recommend having a Sitemap for every category or section of a site.

Speed

A recent O’Reilly report indicated that page load time and the ease with which the Googlebot can crawl a page may affect how many pages are indexed. The logic is that the faster the Googlebot can crawl, the greater number of pages that can be indexed.

This could involve simplifying the structures and/or navigation of the site. The spiders have difficulty with Flash and Ajax. A text version should be added in those instances.

Google’s crawl caching proxy

Matt Cutts provides diagrams of how Google’s crawl caching proxy at his blog. This was part of the Big Daddy update to make the engine faster. Any one of three indexes may crawl a site and send the information to a remote server, which is accessed by the remaining indexes (like the blog index or the AdSense index) instead of the bots for those indexes physically visiting your site. They will all use the mirror instead.

Verify

Verify the site with Google using the Webmaster tools.

Content, content, content

Make sure content is original. If a verbatim copy of another page, the Googlebot may skip it. Update frequently. This will keep the content fresh. Pages with an older timestamp might be viewed as static, outdated, or already indexed.

Staggered launch

Launching a huge number of pages at once could send off spam signals. In one forum, it is suggested that a webmaster launch a maximum of 5,000 pages per week.

Size matters

If you want tens of millions of pages indexed, your site will probably have to be on an Amazon.com or Microsoft.com level.

Know how your site is found, and tell Google

Find the top queries that lead to your site and remember that anchor text helps in links. Use Google’s tools to see which of your pages are indexed, and if there are violations of some kind. Specify your preferred domain so Google knows what to index.

The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the world-wide availability of skilled engineers, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, and YouTube are used to calculate the ratings. Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. The definition of the TIOBE index can be found here.

Position Jan 2008	Position Jan 2007	Delta in Position	Programming Language	Ratings Jan 2008	Delta Jan 2007	Status
1	1		Java	20.849%	+1.69%	A
2	2		C	13.916%	-1.89%	A
3	4		(Visual) Basic	10.963%	+1.84%	A
4	5		PHP	9.195%	+1.25%	A
5	3		C++	8.730%	-1.70%	A
6	8		Python	5.538%	+2.04%	A
7	6		Perl	5.247%	-0.99%	A
8	7		C#	4.856%	+1.34%	A
9	12		Delphi	3.335%	+1.00%	A
10	9		JavaScript	3.203%	+0.36%	A
11	10		Ruby	2.345%	-0.17%	A
12	13		PL/SQL	1.230%	-0.34%	A
13	11		SAS	1.204%	-1.14%	A
14	14		D	1.172%	-0.16%	A
15	18		COBOL	0.932%	+0.30%	A
16	46		Lua	0.579%	+0.48%	A–
17	22		FoxPro/xBase	0.506%	+0.05%	B
18	19		Pascal	0.456%	-0.11%	B
19	16		Lisp/Scheme	0.413%	-0.26%	A–
20	27		Logo	0.386%	+0.07%	B

• Python has been declared as programming language of 2007. It was a close finish, but in the end Python appeared to have the largest increase in ratings in one year time (2.04%). There is no clear reason why Python made this huge jump in 2007. Last month Python surpassed Perl for the first time in history, which is an indication that Python has become the “de facto” glue language at system level. It is especially beloved by system administrators and build managers. Chances are high that Python’s star will rise further in 2008, thanks to the upcoming release of Python 3.
• A couple of interesting trends can be derived from the 2007 data. First of all, languages without automated garbage collection are losing ground rapidly. The most prominent examples of languages with explicit memory management, C and C++, both lost about 2% in one year. Another trend is that the battle between scripting languages seems to be going on in the background. There is a continuous flow of new scripting languages. In 2006, Ruby entered the main scene, followed this year by Lua. In the top 50, Groovy and Factor are new kids on the block. None of these new scripting languages seem to stay permanently, they are just replaced by successors.
• What were the big movers and shakers in 2007? The big winners are Lua (from 46 to 16), Groovy (from 66 to 31), Focus (from 78 to 41), and Factor (new at 45). The most prominent shakers are ABAP (from 15 to 29) and IDL (from 23 to 48).
• What is to be expected in 2008? And, what became of the forecasts for 2007? At the beginning of 2007, I thought C# and D would become the winners and Perl and Delphi the losers. C# was indeed one of the big winners, and Perl one of the big losers. But the forecasts for D and Delphi were completely wrong. There has been no breakthrough for D. On the other hand, Delphi reclaimed a top 10 position… What about 2008? C, C++ and Perl will continue to fall. C and C++ because they have no automated garbage collection. C++ will get an extra push down because Microsoft is not actively supporting the language anymore. Perl is just dead. Java and C# will eventually be the 2 most popular languages. So I expect them to rise further in 2008. What new languages will enter the top 20 in 2008 is a wild guess, but I think ActionScript and Groovy are really serious candidates.
• Nguyen Quang Chien suggested to rename the OCaml entry to Caml. This has been done. Thanks Nguyen!
• In the tables below some long term trends are listed about categories of languages. The tables show that dynamically typed object-oriented languages are still becoming more popular.
  

  Category	Ratings January 2008	Delta January 2007
  Object-Oriented Languages	56.1%	+4.0%
  Procedural Languages	40.9%	-3.6%
  Functional Languages	1.9%	+0.2%
  Logical Languages	1.1%	-0.6%

  Category	Ratings January 2008	Delta January 2007
  Statically Typed Languages	56.2%	-1.5%
  Dynamically Typed Languages	43.8%	+1.5%

Results

2007 Overall Open Source Content Management System Award:

1. Drupal
2. Joomla!
3. CMS Made Simple

Read on for more details about the Overall Open Source CMS Award result

Most Promising Open Source Content Management System:

1. MODx
2. TYPOlight, dotCMS

Read on for more details about the Most Promising Open Source CMS result

Best PHP Open Source Content Management System:

1. Joomla!
2. Drupal
3. e107

Read on for more details about the Best PHP Open Source CMS result

Best Other Open Source Content Management System:

1. mojoPortal
2. Plone
3. Silva

Read on for more details about the Best Other Open Source CMS result

Best Open Source Social Networking Content Management System:

1. WordPress
2. Drupal, Elgg

Read on for more details about the Open Source Social Networking result

• Overall Winner
• Most Promising Open Source CMS
• Best Open Source PHP CMS
• Best Other Open Source CMS
• Best Social Networking CMS:
  

After more than 18,000 votes, we’ve now closed the voting for the 2007 Open Source CMS Awards. Votes are currently being counted and the judges decisions are coming through . The winners will be announced starting from Monday 29 October, in the following order:

Monday 29 October:
Best Open Source Social Networking CMS

Winner: WordPress
Joint Runners up: Drupal & Elgg

Tuesday 30 October:
Best Other Open Source CMS

Winner: mojoPortal
First Runner up: Plone
Second Runner up: Silva

Wednesday 31 October:
Best Open Source PHP CMS

Winner: Joomla!
First Runner up: Drupal
Second Runner up: e107

Thursday 1 November:
Most Promising Open Source CMS

Winner: MODx
Joint Runners up: TYPOlight, dotCMS

Friday 2 November:
Overall Winner

Winner: Drupal
First Runner up: Joomla!
Second Runner up: CMS Made Simple