PHP secure programming-some principles of website security design

The main content of this article is about some principles of website security design in PHP security programming. Now I will share it with you here. Friends who are interested can take a look

Defense in Depth

The principle of defense in depth is a well-known principle among security professionals. It illustrates the value of redundant security measures, which has been proven by history. .

The principle of defense in depth can be extended to other fields, not just limited to programming. Skydivers who have used backup parachutes can attest to the value of having redundant safety measures, although one never wants the main parachute to fail. A redundant security measure can play a significant role in the potential failure of primary security measures.

Back in the field of programming, adhering to the principle of defense in depth requires that you always have a backup plan. If one security measure fails, another must provide some protection. For example, it is a good practice to reauthenticate users before performing important operations, even if there are no known flaws in your user authentication logic. If an unauthenticated user pretends to be another user in some way, prompting for a password can potentially prevent the unauthenticated (unverified) user from performing some critical operations.

Although defense in depth is a sound principle, excessively adding security measures can only increase costs and reduce value.

MINIMUM PERMISSION

I had a car in the past that had a maid key. This key can only be used in the ignition, so it cannot open the doors, console, or trunk. It can only be used to start the car. I can give it to the parking attendant (or leave it in the ignition), and I confirm that the key cannot be used for other purposes.

It makes sense to give the parking attendant a key that won't open the console or trunk; after all, you might want to keep valuables in those places. But what doesn't make sense to me is why it can't open the door. Of course, this is because my point is about the revocation of authority. I was wondering why the parking attendant was stripped of his authority to open the door. In programming, this is a very bad idea. Instead, you should consider what permissions are necessary and give each person as little permission as they need to do their job.

One reason why a maid key cannot open a car door is that the key can be copied, and the copied key may be used to steal a car in the future. This scenario may sound unlikely, but it's an example of how unnecessary authorization can increase your risk, even for a small increase in permissions. Risk minimization is a major component of safety program development.

You don't need to think about all the ways a permission can be abused. In fact, it's nearly impossible to predict every potential attacker's actions.

Simplicity is beautiful

Complexity breeds errors, and errors can lead to security vulnerabilities. This simple fact illustrates why simplicity is so important for a secure application. Unnecessary complexity is just as bad as unnecessary risk.

For example, the following code is excerpted from a recent security vulnerability notice:

<?php
	 
	$search = (isset($_GET[&#39;search&#39;]) ? $_GET[&#39;search&#39;] : &#39;&#39;);
 
?>

This process can confuse the fact that the $search variable is tainted*, especially to inexperienced developers ( Note: A contaminated variable means that during program execution, the value of the variable is not directly specified by the assignment statement, but comes from other sources, such as console entry, database, etc.). The above statement is equivalent to the following program:

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

The above two processing flows are exactly the same. Now please pay attention to the following statement:

$search = $_GET['search'];

Using this statement ensures that the state of the $search variable remains intact without affecting the process, and it can also be seen whether it is contaminated.

Exposure Minimization

PHP applications require frequent communication between PHP and external data sources. The main external data sources are client browsers and databases. If you track the data correctly, you can determine which data was exposed. The Internet is the primary source of exposure because it is a very public network and you must always be careful to prevent data from being exposed on the Internet.

Data exposure does not necessarily mean a security risk. However, data exposure must be minimized as much as possible. For example, when a user enters a payment system and transmits his credit card data to your server, you should use SSL to protect it. If you want to display his credit card number on a confirmation page, since the card number information is sent from the server to his client, you must also use SSL to protect it.

For example, in the previous example, showing credit card numbers obviously increases the chance of exposure. SSL does reduce the risk, but the best solution is to completely eliminate the risk by only displaying the last four digits.

To reduce exposure to sensitive data, you must identify what data is sensitive, track it, and eliminate any unnecessary data exposure. In this book, I'll show you some techniques to help you protect many common types of sensitive data.

Related recommendations:

Common PHP security attacks and solutions

Detailed explanation of PHP security examples

Detailed explanation of PHP security development library

The above is the detailed content of PHP secure programming-some principles of website security design. For more information, please follow other related articles on the PHP Chinese website!