This can be useful for a hacker to get the username right. A good idea is to display a generic message as given below.

You can easily achieve that by adding the following line to your themes ‘functions.php’ file.

add_filter('login_errors',
            create_function('$no_login_error', 
                            "return 'Oops! Wrong Credentials.';"));

The second argument to the ‘add_filter’ creates a anonymous callback function. This is equivalent to the following.

function no_login_error() {
    return 'Oops! Wrong Credentials.';
}
 
add_filter('login_errors','no_login_error');

WordPress File Monitor
WFM monitors your WordPress installation for any added, deleted or changed files. When a change is detected an email is sent to a specified address. Currently does not support multi-site installations.

Ultimate Security Checker
Ultimate Security Checker helps you identify security problems with your WordPress installation. It scans your WordPress blog for hundreds of known threats, then gives you a security “grade” based on how well you have protected yourself.

It has now been removed and to prevent any such changes to the .htaccess file in the future, I’ve written a small php script that compares the hash (SHA1) of the two major files that usually get compromised and compare them to the one originally stored. The script will run as a cron job and notify me by email if any changes are seen. This is a quick workaround which needs some more work done.

<?php
 
$hash1 = sha1_file('.htaccess');
$hash2 = sha1_file('index.php');
 
if(($hash1 == 'fa7cdb22b81b0b713bfed609acc984591f9bed2f') && 
   ($hash2 == 'b4bb6070800a340566d7d6872516d248d4a7aff3')) {
    mail("EMAIL", "Status Ok!", "Status Ok!");
} else {
    mail("EMAIL", "Alert!", "Files have changed!");
}    
?>

Of-course there are other ways the site can get hacked, but the last couple of times my site got compromised was for these reasons. So at-least I’ve one area covered.

One of my concerns is related to the ‘Challenge Questions’ provided by major websites such as Gmail, Hotmail for authentication, mostly during account recovery. Take for example the Challenge Question offered by Gmail:

What is the name of your manager at your first job?
What is the name of your best friend from childhood?
What was the name of your first teacher?

Answers to most of the above questions can be garnered by a little digging around your social stream, making it easier for the malicious person to hack your account. Aggregators such as IdentEngine, a Javascript library, can make it even easier to locate your profiles around the social web. In short, the social web “leaks” security information.

When Scott McNealy remarked in 1999, “You have zero privacy anyway,Get over it.”, he was right on the technical front but wrong otherwise. You still have control over of how much personal information about you floats around the web; it may be a little harder but not impossible. The important point is to be alert and proactive when divulging important information around the web.

As a programming language, PHP has many advantages but security has always been a major issue. Partially these security problems are inherent to the language itself because PHP was meant to be an easy and powerful programming language, while security came second. However, when you add bad coding and non-adherence to even the basic security rules, the situation gets out of control.

Fortunately, it is possible to fix PHP vulnerabilities and make PHP applications more secure. Some of the defenses are common for all programming languages, while others are found only in PHP. Here are some of the best defenses you have when you want to fix PHP vulnerabilities and make your site more secure.

Defend Your Code Against SQL Injections

SQL Injection is one of the most typical PHP vulnerabilities and many hackers take advantage of it. In order to prevent SQL injections, you need to always check input data and to escape characters (such as single quotes (‘) or double quotes (“)). If you do it, it won’t be possible to execute malicious SQL queries, which take control over your database or compromise the security of your site in other ways.

The two most common defenses against SQL injections are the use of the mysql_real_escape_string and PDO. The mysql_real_escape_string prepends special characters and as a result these special characters are not sent directly to the MySQL database. It is recommendable to use mysql_real_escape_string on all input variables, which are sent to the MySQL database.
PDO adds an abstraction layer to your code, thus making it more secure. PDO prepares a statement for execution and returns a statement object.

Don’t Leave Room for Cross-Site Scripting Vulnerabilities

Cross-Site Scripting (XSS) is also common in PHP. Again, the defense against XSS isn’t rocket science. If the users input HTML data is escaped properly, your code won’t be vulnerable against XSS. If you don’t do it, then a hacker can insert any HTML code (or even Javascript) he or she likes and modify your page, so that he or she can steal data from users.

The best defense against XSS is to use the htmlspecialchars() function. This function identifies any output you wouldn’t like to be considered as HTML output. While you can never be certain that XSS is impossible, the htmlspecialchars() function will make it harder for a hacker to succeed.

Watch out for File Inclusion Vulnerabilities

Of all PHP vulnerabilities, file inclusion attacks are the most severe. A file inclusion attack gives the hacker the opportunity to include a random file and to deploy it on your server. File inclusion attacks are possible when the register_globals directive is on, which means that unchecked input variables are allowed. The best defense against file inclusion vulnerabilities is to mind how you use PHP include() functions. If you are not sure you can use these functions properly, you’d better avoid any include statements – just use switch statements with hard coded strings and this will help to avoid file inclusion vulnerabilities.

Don’t Forget to Initialize Variables

If you program in many other languages, then you maybe don’t need to be told explicitly to initialize variables because you already have the habit of doing it. However, if you are mainly a PHP programmer, maybe you don’t always initialize variables because in PHP, unlike in many other programming languages, a variable can be used without being initialized first. From a security point of view, uninitialized variables are a huge risk and this is why you should never use them.

Don’t Leave the register_globals Directive ON

File inclusion attacks aren’t the only evil the register_globals directive brings to your code. The register_globals directive is very powerful but unfortunately its power is easily abused. In recent versions of PHP the directive register_globals is OFF by default and in PHP 6 it is altogether removed but if you are using earlier versions of PHP, take the time and check if it isn’t ON by accident.

Encryption Always Helps

No matter which programming language you use, encryption always helps. It doesn’t matter how secure your PHP code is when you send sensitive data unencrypted and anybody can read it. The safest form of encryption is end-to-end encryption but it takes a lot of resources and it might be hard to implement. This is why it is acceptable if you encrypt at least passwords, credit card numbers, and other similar data. Don’t leave sensitive data unencrypted because this is what hackers want most.

Test Your PHP Code with Tools

There are many PHP tools to test the security of your code with. Sure, you should do your best to write secure code, adhere to security practices, and carefully review your code for errors but an automated tool to check your code with is always useful. Some of the best tools to test PHP vulnerabilities with are PhpSecInfo, PHP Security Scanner, and Spike PHP Security Audit Tool. Run them on your code and see what they will find.

Further Reading

These steps are just the beginning to make your PHP code secure. You must always take at least these steps because if you don’t you leave the door wide open to hackers. On the other hand, even if you do everything we described here, you can never be sure that no vulnerabilities exist. There is much more to PHP security and if you want to expand your knowledge, read the PHP Security manual and this paper. Both of them will tell you more about how to fix PHP vulnerabilities and make your site secure.

This guest article was written by Christopher Shepard of Webhost Gear, a website that provides information about hosting and reviews of the most popular web hosting services, as well as technical and website maintenance tutorials.

The PHP script reads two text files – ‘malicious.txt and ‘urls.txt’ : the first containing a list of web pages to be scanned and the other containing malicious script signatures. The script scans the urls for malicious scripts and if any infections are found it saves the result in the ‘infected.txt’ file. The script needs to be run from the command line as you can easily see the progress of the scan if you are scanning a large number of urls.

D:\localhost\test\scan>php url_scan.php

A sample output of a scan is show below:

 
D:\localhost\test\scan>php url_scan.php
 
Checking 3 sites for malicious scripts.
3 malicious signatures in file.
---------------------------------------------------------
 
Now scanning :http://www.amazon.com/
[OK]
---------------------------------------------------------
 
Now scanning :http://www.google.com/
[OK]
---------------------------------------------------------
 
Now scanning :http://www.example.com/admin.php
[OK]
---------------------------------------------------------
 
Total 0 sites infected of 3

Note that the script only scans the url path given and not the complete web site. So if given a url like ‘http://www.example.com’ it will only scan the index file of the site. It may happen that the index file may not be infected but some other file in a sub-directory is, in that case the malicious code will not be found. But a larger percentage of malicious script injections are usually inflicted on the index page.

Setting a cron for automatic scanning

The best way to regularly check for any infections is to setup the script as a cron job. This can help you in checking malicious script on a regular interval, the cron job can then send the ‘infected.txt’ file via a email if any infections are found.

Updating your malicious.txt file

You cannot fight new code injections if your ‘malicious.txt’ file is not updated. So if you find some new malicious Javascript code, then it is essential that you include a new signature in the file. Well I know I’m putting the cart before the horse but you can find various new information about infections at malware.com.br or malwaredomainlist.

Other ways to check malicious code injections

One main problem with the script is that if some new infection occurs and the signature is not in the ‘malicious.txt’ database then that particular infection will be missed. One other solution is to check the filesize of the particular url you are checking. The filesize needs to be added to the ‘urls.txt’ file, so the script can check to see if the filesize of the url scanned is the same as the one given. But for that we will need to use the ftp functions of php but we will leave that to another post.

According to the Mitre site:

The main goal for the Top 25 list is to stop vulnerabilities at the source by educating programmers on how to eliminate all-too-common mistakes before software is even shipped. The list will be a tool for education and awareness that will help programmers to prevent the kinds of vulnerabilities that plague the software industry. Software consumers could use the same list to help them to ask for more secure software. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software.

The 25 vulnerabilities are divided into three main categories: Insecure Interaction Between Components, Risky Resource Management and Porous Defenses, details of which are listed below.

Insecure Interaction Between Components

These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.

* Improper Input Validation
* Improper Encoding or Escaping of Output
* Failure to Preserve SQL Query Structure (‘SQL Injection’)
* Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
* Improper Sanitization of Special Elements used in an OS Command (‘OS Command Injection’)
* Cleartext Transmission of Sensitive Information
* Cross-Site Request Forgery (CSRF)
* Race Condition
* Error Message Information Leak

Risky Resource Management

The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.

* Failure to Constrain Operations within the Bounds of a Memory Buffer
* External Control of Critical State Data
* External Control of File Name or Path
* Untrusted Search Path
* Failure to Control Generation of Code (‘Code Injection’)
* Download of Code Without Integrity Check
* Improper Resource Shutdown or Release
* Improper Initialization
* Incorrect Calculation

Porous Defenses

The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.

* Improper Access Control (Authorization)
* Use of a Broken or Risky Cryptographic Algorithm
* Hard-Coded Password
* Incorrect Permission Assignment for Critical Resource
* Use of Insufficiently Random Values
* Execution with Unnecessary Privileges
* Client-Side Enforcement of Server-Side Security

The SANS Institute proclaims that the document will have four major impacts on the industry.

* Software buyers will be able to buy much safer software.
* Programmers will have tools that consistently measure the security of the software they are writing.
* Colleges will be able to teach secure coding more confidently.
* Employers will be able to ensure they have programmers who can write more secure code.

However, it remains to be seen how fast the changes really occurs.

In practice

So as a PHP programmer what can you do to bring security into your development process.
The first is to acknowledge that the problem exists.
Second, convince management that spending time on security will be profitable to the company in the long term and will keep them from being sued by clients if a security breach occurs.
Third, get some good books on secure programming. I would personally recommend:
1. Pro PHP Security: by Chris Snyder, Michael Southwell
2. Essential PHP Security: by Chris Shiflett
3. php|architect’s Guide to PHP Security: by Ilia Alshanetsky
4. Web Security Testing Cookbook: Paco Hope, Ben Walther
5. Security Engineering: Ross J. Anderson

1. Principle of least privilege:
A subject should be given only those privileges that it needs in order to complete task. The principle of least privilege states that only the minimum access necessary to perform an operation should be granted, and that access should be granted only for the minimum amount of time necessary.

2. Fail-safe defaults:
Unless a subject is given explicit access to an object, it should be denied access to that object. Design your sites so that when it fails, it fails in a secure manner. For example when an ATM fails, it should shut down, and not spew money out its slot.

For example take the following code in PHP:

$access = $IsAccessAllowed($user); 
if ($access == ERROR_ACCESS_DENIED) 
{ 
// Security check failed.
// Inform user that access is denied. 
} 
else 
{ 
// Security check OK. 
}

The code looks fine, but what if the IsAccessAllowed function fails. The default execution path in the above code is to grant access to the user. A better version is show below. Here the default access is set to ‘DENIED’. Only after IsAccessAllowed is successfully executed and it returns a ‘NO_ERROR’ message is the user allowed access.If for any reason the IsAccessAllowed function fails the default action is to deny access.

$access = ERROR_ACCESS_DENIED; 
$access = $IsAccessAllowed($user); 
if ($access == NO_ERROR) 
{ 
// Secure check OK. 
// Perform task. 
} 
else 
{ 
// Security check failed. 
// Inform user that access is denied. 
}

3. Economy of mechanism:
Security mechanisms should be as simple as possible. Security is like a chain; the weakest link breaks it. Simplicity means fewer links and fewer points of vulnerability.

4. Complete mediation:
All access to objects be checked to ensure that they are allowed. Every access to every object must be checked for authority.

5. Open design:
Security of a mechanism should not depend on the secrecy of its design or implementation.

6. Psychological acceptability:
Security mechanisms should not make the resource more difficult top access than if the security mechanisms were not present. The security mechanism should be designed taking the user in mind. For example; If a user on your website has to set a dozen permissions on his profile page or payment preferences, he will surely give it a miss, thus opening a security hole hackers can exploit.

The details of security mechanism implementation can vary for various web languages like PHP or .NET, but keeping the above principle in mind can go a long way in securing you website.

For more detailed and excellent information you can visit here.