创建 php 博客时应包括哪些安全措施？
我正在编写一个 php 博客应用程序，我听说应该考虑某些安全措施。我正在使用 PHP PDO 来过滤条目数据和评论，但我听说了 rel="nofollow" 并且不确定那是什么？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一些快速提示：
Some quick pointers:
尽管您询问了
rel=nofollow，但我正在回答标题“创建 php 博客时要包含哪些安全性？”的更大范围的问题。从问题的措辞来看，您似乎正在尝试找出在代码中放入什么内容以提供一定的安全性，并且基于有关rel=nofollow的问题，我将假设安全目前不是您的专长。我将在这个回复中建议，虽然这些事情很重要，但你的范围可能太窄了。许多人将应用程序安全视为使用何种编码技术的问题 - 换句话说，严格将其视为实施任务。虽然这在微观层面上很重要，但只有从宏观层面融入这一过程才能成功。不存在断章取义的安全代码。它在更大的系统中运行，与许多其他程序交互并由人类使用。在开始编码之前，有必要考虑如何保护整个系统的安全。这包括如何管理系统开发生命周期（代码审查、白盒和黑盒扫描、变更管理等）、是否将安全性设计到架构中（而不是事后添加）等考虑因素，或者最终用户为使安全性发挥作用所需的交互的数量和性质（即默认情况下是否安全，或者用户需要配置什么来启用安全性）。
回到创建博客时要包含哪些安全性的问题，请查看以下站点：
IBM 安全工程框架
链接的文档很好地介绍了如何在整个项目生命周期的系统级别上实现安全性。以下摘录让您了解范围：
如果目标是编写安全的博客应用程序，则必须考虑上述所有方面。请注意，其中许多是架构而不是代码级细节。例如，考虑一下审核日志记录。如何确保安全？您需要考虑日志是否会滚动，因为攻击者可能会淹没日志，直到攻击证据滚动为止。如果它们不翻转，那么攻击者就可以淹没它们，直到磁盘上没有剩余空间。如果发生这种情况，应用程序是否会停止或者日志记录是可选的？安全相关事件是否与常规消息保存在同一日志中？ ID 和密码或其他个人身份信息是否转储到日志中以供调试？跨所有类别的这些类型问题的答案决定了代码级实现必须运行的结构。
支付卡行业数据安全标准
尽管 PCI-DSS 的开发目的是应用于处理卡支付交易的系统，但它越来越被视为衡量 IT 安全性的基线。事实上，截至撰写本文时，内华达州和马萨诸塞州已颁布数据隐私法来保护其公民，要求收集这些州公民数据的任何人实施与 PCI-DSS 要求相同的安全级别。
PCI-DSS 有 6 个类别，总共包含 12 个子类别。高级别类别包括：
请注意，其中三个是实施和设计，但其中三个 -整整一半的要求 - 与人的流程有关。
漏洞管理计划要求意味着熟悉安全性的人员将负责及时了解提供系统组件的不同供应商（包括开源框架、商业产品，甚至 SSL 和 TLS 等标准）的最新安全新闻，然后确保对您的代码进行重要的安全补丁并及时向用户推出。事实上，轻松更新代码并将其发布给用户的能力是安全设计的一个重要方面。
定期监控和测试的要求是另一个可操作的人力流程要求。安全配置会随着时间的推移而降低。这是因为攻击变得更好，但也是因为您的安全所依赖的外部配置可能会在您不知情的情况下发生变化。与您在代码中放入的内容同样重要的是您在部署代码后执行的操作。请注意，为了执行此级别的监视和测试，应用程序设计必须预见到这一点，并提供一定数量的日志记录和关键性能指标（或 KPI），以便可以客观地测量应用程序。另请注意，测试必须包括负面结果和正面结果。
维护信息安全策略的要求认识到，就像代码一样，安全工程的有效性必须形式化且可衡量，才能最有效。如果没有书面的安全计划并对其进行定期审查，就无法知道安全措施的级别。随着时间的推移，响应时间和用户界面等功能要求往往会将安全性推到优先级列表的底部，因此，未能定期评估该领域的性能实际上保证了日常实践的安全性会随着时间的推移而变得更糟。
总结
总而言之，当安全性被零碎地对待时，作为附加的补充，或者严格地作为编码技术的问题，那么它是不完整的，并且在许多情况下是无效的。安全性必须在整个系统开发生命周期中由所有涉及的学科（架构师、编码员、系统管理员等）实施。如果您的应用程序将在稍微有敌意的环境中出售或使用，那么除了任何特定的编码技术之外，您还应该从整个系统的角度来处理安全问题。也许你已经在这样做了，如果是这样，我为你鼓掌。但如果这是新信息，我鼓励您熟悉链接的资源，并决定所描述的方法有多少适用于您的项目。
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 aboutrel=nofollowI'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:
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:
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.
来自 http://en.wikipedia.org/wiki/Nofollow
当允许用户在您的网站上发布链接（例如在评论中）时，这一点很重要。将此属性添加到所有用户提供的链接将有助于阻止垃圾邮件发送者使用您的网站来提高其页面排名。
编辑：正如您从我上面使用的链接中看到的那样，stackoverflow 使用了这种策略。
From http://en.wikipedia.org/wiki/Nofollow
This is important when allowing users to post links on your site (in comments for example). Adding this attribute to all user-contributed links will help dissuade spammers from using your site as a way to increase their page ranks.
Edit: As you can see from the link I used above stackoverflow uses this tactic.
rel="nofollow"并不是真正的安全功能。它向搜索引擎表明您的网站不认可链接 URL 的内容。对于博客，它最常应用于评论中的链接，因为它们是用户提交的内容，您不一定会验证。rel="nofollow"isn't really a security feature. It indicates to search engines that your site doesn't endorse the contents of the linked URL. For blogs, it's most commonly applied to links in comments, as they're user submitted content that you haven't necessarily verified.