Section 1.2. Principles

1.2. Principles

You can adopt many principles to develop more secure applications. I have chosen a small, focused list of the principles that I consider to be most important to a PHP developer.

These principles are intentionally abstract and theoretical in nature. Their purpose is to provide a broad perspective that can guide you as you focus on the details. Consider them your road map.

1.2.1. Defense in Depth

Defense in Depth is a well-known principle among security professionals. It describes the fact that there is value in redundant safeguards, and history supports this.

The principle of Defense in Depth extends beyond programming. A skydiver who has ever needed to use a reserve canopy can attest to the value in having a redundant safeguard. After all, the main canopy is never meant to fail. A redundant safeguard can potentially save the day when the primary safeguard fails.

In the context of programming, adhering to Defense in Depth requires that you always have a backup plan. If a particular safeguard fails, there should be another to offer some protection. For example, it is a good practice to prompt a user to reauthenticate before performing some important action, even if there are no known flaws in your authentication logic. If an unauthenticated user is somehow impersonating another user, prompting for the user's password can potentially prevent the unauthenticated (and therefore unauthorized) user from performing a critical action.

Although Defense in Depth is a sound principle, be aware that security safeguards become more expensive and less valuable as they are accrued.

1.2.2. Least Privilege

I used to drive a car that had a valet key. This key worked only in the ignition, so it could not be used to unlock the console, the trunk, or even the doorsit could be used only to start the car. I could give this key to someone parking my car (or simply leave it in the ignition), and I was assured that the key could be used for no other purpose.

It makes sense to give a key to a parking attendant that cannot be used to open the console or trunk. After all, you might want to lock your valuables in these locations. What didn't make sense to me immediately was why the valet key cannot open the doors. Of course, this is because my perspective was that of revoking privilegeI was considering why the parking attendant should be denied the privilege of opening the doors. This is not a good perspective to take when developing web applications. Instead, you should consider why a particular privilege is necessary, and provide all entities with the least amount of privilege required for them to fulfill their respective responsibilities.

One reason why the valet key cannot open the doors is that the key can be copied. Such a copy can be used to steal the car at a later date. This situation might seem unlikely (it is), but this illustrates why granting an unnecessary privilege can increase your risk, even if the increase is slight. Minimizing risk is a key component of secure application development.

It is not necessary that you be able to think of all of the ways that a particular privilege can be exploited. In fact, it is practically impossible for you to be able to predict the actions of every potential attacker. What is important is that you grant only least privilege. This minimizes risk and increases security.

1.2.3. Simple Is Beautiful

Complication breeds mistakes, and mistakes can create security vulnerabilities. This simple truth is why simplicity is such an important characteristic of a secure application. Unnecessary complexity is as bad as an unnecessary risk.

For example, consider the following code taken from a recent security vulnerability notice:

     <?php     $search = (isset($_GET['search']) ? $_GET['search'] : '');     ?> 

This approach can obscure the fact that $search is tainted, particularly for inexperienced developers. Contrast this with the following:

     <?php     $search = '';     if (isset($_GET['search']))     {       $search = $_GET['search'];     }     ?> 

The approach is identical, but one line in particular now draws much attention:

     search = $_GET['search']; 

Without altering the logic in any way, it is now more obvious whether $search is tainted and under what condition.

1.2.4. Minimize Exposure

PHP applications require frequent communication between PHP and remote sources. The primary remote sources are HTTP clients (browsers) and databases. If you properly track data, you should be able to identify when data is exposed. The primary source of exposure is the Internet, and you want to be particularly mindful of data that is exposed over the Internet because it is a very public network.

Data exposure isn't always a security risk. However, the exposure of sensitive data should be minimized as much as possible. For example, if a user enters payment information, you should use SSL to protect the credit card information as it travels from the client to your server. If you display this credit card number on a verification page, you are actually sending it back to the client, so this page should also be protected with SSL.

In this particular scenario, displaying the credit card number to the user increases its exposure. SSL does mitigate the risk, but a better approach is to eliminate the exposure altogether by displaying only the last four digits (or any similar approach).

In order to minimize the exposure of sensitive data, you must identify what data is sensitive, keep track of it, and eliminate all unnecessary exposure. In this book, I demonstrate some techniques that can help you minimize the exposure of many common types of sensitive data.

Essential PHP Security
Essential PHP Security
ISBN: 059600656X
EAN: 2147483647
Year: 2005
Pages: 110

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: