创建php博客时要包含哪些安全性？

Question

I am writing a php blog application and I have heard that there are certain security measurements that should be taken into consideration. I am using PHP PDO to filter the entry data and comments, but I heard about rel="nofollow" and I was unsure what that was?

Answer 1

Although you asked about rel=nofollow, I'm responding to the greater scope of the question title "What security to include when creating a php blog?" From the wording of the question it sounds like you are approaching this as trying to find out what to put in the code to provide some security, and based on the question about rel=nofollow I'm going to assume that security is not currently your specialty. I'm going to suggest in this response that, although these things are important, your scope may be too narrow.

Many people approach application security as a question of what coding techniques to use - in other words strictly as an implementation task. While this is important at a micro level, it is only successful if baked into the process from a macro level. There is no such thing as secure code taken out of context. It runs in a larger system, interacts with a lot of other programs and is used by humans. Before you even get to code it is necessary to consider how the system as a whole will be secured. That includes such considerations as how the system development lifecycle is managed (code review, white box and black box scanning, change management, etc.), whether security is designed into the architecture (as opposed to being bolted on as an afterthought), or the amount and nature of the interaction required from the end user to make the security work (i.e. whether it is secure by default or what the user is required to configure to enable security).

Getting back to the question of what security to include when creating a blog, have a look at these sites:

IBM Secure Engineering Framework
The linked document provides a good introduction to how security is approached at a systemic level throughout the lifecycle of the project. The following excerpt gives you an idea of the scope:

The SEF suggests nine categories for security requirements and provides examples for each category. These include:

1. Auditing and logging
2. Authentication and authorization
3. Session management
4. Input validation and output encoding
5. Exception management
6. Cryptography and integrity
7. Data at rest
8. Data in motion
9. Configuration management

All of the above aspects must be considered if the objective is to write a secure blogging application. Note that many of them are architecture rather than code-level details. For example, consider audit logging for a minute. How do you make that secure? You need to consider whether the logs roll over because an attacker could flood them until evidence of the attack has rolled off. If they do not roll over then an attacker can flood them until there is no space left on disk. If that happens, does the application stop or is logging optional? Do security-related events go in the same log as routine messages? Are IDs and passwords or other personally identifiable information dumped to the log for debugging? The answers to these types of question, across all of the categories, determine the structure within which the code-level implementation must operate.

Payment Card Industry Data Security Standard
Although PCI-DSS was developed to apply to systems handling card payment transactions, it is increasingly viewed as the baseline against which IT security is measured. In fact, as of this writing both Nevada and Massachusetts have enacted data privacy laws to protect their citizens by requiring anyone collecting data on the citizens of those states to implement the same level of security as PCI-DSS requires.

PCI-DSS has six categories which are compromised of a total of 12 sub-categories. The high-level categories are:

• Build and Maintain a Secure Network
• Protect Cardholder Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

Notice that three of these are implementation and design but three of them - fully half of the requirements - are about human processes.

The vulnerability management program requirement means that someone familiar with security would be responsible for staying current on the security news from the different vendors who supplied components of the system (which includes open source frameworks, commercial products, even standards like SSL and TLS) and then make sure that important security patches are made to your code and rolled out to users in a timely fashion. Indeed, the ability to easily update the code and roll it out to users is an important aspect of security design.

The requirement for regular monitoring and testing is another operational human process requirement. Security configurations degrade over time. This is because the attacks get better but it is also because external configurations on which your security relies can change without you knowledge. Just as important as what you put in the code is what you do after the code is deployed. Note that in order to perform this level of monitoring and testing, the application design must have anticipated this and provided a certain amount of logging and key performance indicators (or KPIs) so that the application can be objectively measured. Note also that the testing must include negative outcomes as well as positive outcomes.

The requirement to maintain an Information Security Policy recognizes that, just like code, the effectiveness of your security engineering must be formalized and measurable to be most effective. Without a written security plan and a periodic review of it, there is no way to know at what level security is being practiced. Functional requirements such as response time and user interface tend to push security to the bottom of the priority list over time so a failure to periodically assess performance in this area is a virtual guarantee that security as practiced day-to-day will get worse over time.

Summary
To sum up, when security is approached piecemeal, as a bolt-on addition, or strictly as a question of coding techniques then it is incomplete and in many cases ineffective. Security must be practiced throughout the system development lifecycle and by all of the disciplines involved (architects, coders, sysadmins, etc.). If your application will be sold or used in even a slightly hostile environment you should be approaching security from a total system perspective in addition to any specific coding techniques. Perhaps you are doing this already and if so I applaud you. But if this is new information I encourage you to become familiar with the linked resources and decide how much of the methodologies described would apply to your project.