5个其他PHP安全漏洞

In a previous article, I talked about some common security vulnerabilities that can affect your PHP web application. But there are other things besides those ten (okay, seven) attacks to think about when you’re developing. And so, this article offers a compendium of miscellaneous things that are security related; things you should do, things you shouldn’t do, things that other people might try to do, whatever it takes to make an article long enough for my editor to be satisfied with it.

在上一篇文章中 ，我讨论了一些会影响您PHP Web应用程序的常见安全漏洞。 但是除了那十次(好的，七次)攻击之外，还有其他事情要考虑您何时进行开发。 因此，本文提供了与安全相关的其他杂项的概述。 您应该做的事情，您不应该做的事情，其他人可能尝试做的事情，以及使文章足够长以使我的编辑满意的花费。

PHP的安全性配置文件 (PHP’s Security Profile)

Sometimes when you’re hanging around in a bar you hear people (not the regulars, of course, but folks who just wander in) insinuating that PHP is not a very secure language. In the past, there were some legitimate grounds for such feelings.

有时，当您在酒吧中闲逛时，您会听到人们(当然不是普通人，而是刚进入的人们)暗示PHP不是一种非常安全的语言。 过去，这种感觉有一些合理的依据。

Most of the historical problems can be traced to poor default settings. A good example is register globals which was deprecated in 5.3 and then removed entirely in 5.4. There’s no sense talking about it; it’s no longer an issue, but let’s just say that it gave people the opportunity to write potentially insecure code. Insecurities that were a result of php.ini settings have now been mostly neutralized or else are better publicized.

大多数历史问题可以追溯到不良的默认设置。 一个很好的例子是寄存器全局变量，它在5.3中被弃用，然后在5.4中被完全删除。 谈论它没有任何意义。 它不再是一个问题，而只是说它给人们提供了编写潜在的不安全代码的机会。 由php.ini设置引起的不安全性现在已基本消除，或者可以更好地进行宣传。

One big thing in PHP’s favor is that it’s a server-side language. Unlike JavaScript or HTML which is executed directly in the user’s browser or which the code can be viewed, PHP code is interpreted on the server with only the results sent to the browser. Of course if the server is misconfigured it could cause PHP code to be downloaded to the browser, but that’s not the sort of thing that happens every day.

PHP的一大优势是它是一种服务器端语言。 与直接在用户浏览器中执行或可以查看代码JavaScript或HTML不同，PHP代码在服务器上解释为仅将结果发送到浏览器。 当然，如果服务器配置错误，则可能导致PHP代码下载到浏览器，但这不是每天都会发生的事情。

One thing that sometimes gets in PHP’s way, but which is also one of its strengths, is its flexibility. Not everything has to be just such and so for a PHP app to run. You can have loose ends and the code will still work. Unfortunately, loose ends are what keep hackers in business, and so writing secure code often starts with starting with tight, technically correct code.

有时它会妨碍PHP的一件事，但是它的优点之一就是它的灵活性。 并非所有事情都必须如此，PHP应用程序才能运行。 您可能会有松散的结局，代码仍然可以使用。 不幸的是，束手无策是使黑客从事商业活动的根本原因，因此编写安全代码通常始于严格，技术正确的代码。

过滤输入数据 (Filter Input Data)

It sounds so simple: inspect data that is entered on your web pages and make sure it is not dangerous. Like who wouldn’t do that, man? The answer is a surprising number of people.

听起来很简单：检查在网页上输入的数据，并确保它没有危险。 就像谁不会那样做，伙计？ 答案是惊人的人数。

There is a certain school of thought that argues that anyone who is a computer science major should be subjected to a semester’s worth of scams. You know, people coming up to them and offering to give then $100 if they can just advance them the $20 required to get their “check” cashed. Or emails from a lawyer somewhere telling them that a relative they have never heard of has just left them 25-million pounds and all they need to do to claim it is to send their bank information. The goal, of course, is to teach computer people that the world is not a friendly place. We set up a 256-character area for the user to enter comments and some people will use that space to enter SQL commands in an attempt to do an SQL injection attack. Is there no honor anymore?

有一种流派认为，计算机科学专业的任何人都应受到一学期的骗局之害。 你知道吗，人们走过来向他们提出要给他们100美元，如果他们可以将他们的“支票”兑现所需的20美元。 或某处律师发来的电子邮件告诉他们，他们从未听说过的亲戚留下了2500万英镑，而他们所要做的只是声称要发送银行信息。 当然，目标是要向计算机人员教授世界不是一个友好的地方。 我们设置了一个256个字符的区域供用户输入注释，某些人将使用该空间输入SQL命令，以尝试进行SQL注入攻击。 不再有荣誉了吗？

If you set up a page that allows any type of free form entry on it, you need to review that input carefully and make sure that you keep anything bad from being entered. Use the function filter_input() to ensure that bad people don’t put bad things in your forms (or even in your files if your input comes with a file transfer or some other I/O operation).

如果您设置的页面允许在其中输入任何类型的自由格式，则需要仔细检查该输入，并确保不要输入任何不良内容。 使用函数filter_input()可以确保坏人不会在您的表单中(甚至在您的文件中，如果您的输入带有文件传输或其他一些I / O操作)也不会放置坏东西。

Fortunately, there are already two great articles on SitePoint related to that. The first is Input Validation Using Filter Functions by Toby Osbourn, and the second is ClamAV as a Validation Filter in Zend Framework by Matthew Setter. Between these two articles you should be able to get the lowdown on the downlow about this potential problem.

幸运的是，有关SitePoint的文章已经有两篇了。 第一个是Toby Osbourn的使用过滤器功能的输入验证 ，第二个是Matthew Setter的Zend Framework中的ClamAV作为验证过滤器 。 在这两篇文章之间，您应该能够找到有关该潜在问题的最低版本。

错误报告 (Error Reporting)

You might want error messages to appear on your screen during development to give you a hint when something goes wrong with your script. But when you are in production, do you really want this to happen? Every bit of information is life food for a hacker, and even information about your failures may be helpful to those whose only desire is to destroy your site. Consequently, you should never display errors on the screen when you are in production.

您可能希望在开发期间在屏幕上显示错误消息，以便在脚本出现问题时向您提供提示。 但是，当您在生产中时，您真的希望这种情况发生吗？ 每一点信息都是黑客的生命，甚至有关您的失败的信息也可能对那些只想破坏您的网站的人有所帮助。 因此，生产时切勿在屏幕上显示错误。

How do you control this? Thank goodness the php.ini file is there because it is for just such needs as this that it exists. In fact, there are four flags that can be set in php.ini to configure error reporting just as you like.

您如何控制呢？ 谢天谢地，那里有php.ini文件，因为它正是出于这种需要而存在的。 实际上，可以在php.ini设置四个标志，以根据需要配置错误报告。

• error_reporting – this flag decides whether you want to know about errors or not. Obviously, you want to know about everything, so the sensible thing is to set this to E_ALL in both production and test.

  error_reporting –此标志决定您是否要了解错误。 显然，您想了解所有事情，因此明智的做法是在生产和测试中都将其设置为E_ALL 。

• display_errors – this flag indicates whether you want the error messages to be displayed on the screen or not. Set this to “on” during development and “off” for production. There’s no sense in giving hackers any more info than necessary; let them do the heavy lifting.

  display_errors –此标志指示您是否要在屏幕上显示错误消息。 在开发期间将其设置为“ on”，在生产时将其设置为“ off”。 没有必要向黑客提供更多不必要的信息。 让他们做繁重的工作。

• log_errors – indicates whether errors should be logged to a log file. Obviously, you would want this on for production.

  log_errors –指示是否应将错误记录到日志文件中。 显然，您希望将其用于生产。

• error_log – indicates the path to the file where the error messages will be written to. Obviously, for this to take effect, we need to have log_errors turned on.

  error_log –指示将错误消息写入的文件的路径。 显然，要使其生效，我们需要打开log_errors 。

With these flags set, you can get all of the information you need during testing while yet protecting yourself in production.

设置这些标志后，您可以在测试过程中获得所需的所有信息，同时又可以保护自己的生产。

会话固定 (Session Fixation)

In the previous article I talked about session hijacking, but there is another type of attack that can happen to your sessions: session fixation. Fixation is where you are tricked into using a session ID provided by the hacker. How does this happen?

在上一篇文章中，我讨论了会话劫持，但是会话可能会发生另一种攻击：会话固定。 解决方法是诱使您使用黑客提供的会话ID。 这是怎么发生的？

Generally session fixation occurs when you click on a link that contains a PHPSESSID parameter that carries the session ID an attacker wants you to use. That link could take you to a form on which your identity is verified and now your identity is tied to the session ID the attacker has given you, allowing them to view any page in your site and access the data associated with that page.

通常，当您单击包含PHPSESSID参数的链接时，会话固定发生，该参数带有攻击者希望您使用的会话ID。 该链接可以将您带到一个表单，在该表单上可以验证您的身份，现在您的身份已与攻击者提供给您的会话ID绑定在一起，从而允许他们查看您站点中的任何页面并访问与该页面关联的数据。

Fortunately, preventing this is relatively easy. Start by checking out the following values in php.ini:

幸运的是，防止这种情况相对容易。 首先检查php.ini的以下值：

• session.use_cookies – controls the persistence of the session ID when cookies are used. It should be set to 1 or not set at all.

  session.use_cookies –控制使用cookie时会话ID的持久性。 应该设置为1或根本不设置。

• session.use_only_cookies – keeps the ID from being overridden by GET parameters and should be set to 1.

  session.use_only_cookies –防止ID被GET参数覆盖，应设置为1。

• Session.use_trans_sid – makes PHP change the output so that the session ID in links, etc. will persist. This should be set to 0.

  Session.use_trans_sid –使PHP更改输出，以便链接等中的会话ID保持不变。 应该设置为0。

• session.name – the name of the session parameter. Generally this is set to “PHPSESSID” and knowing that makes it a little easier for hackers. Change this to a more obscure value.

  session.name –会话参数的名称。 通常，将其设置为“ PHPSESSID”，并且知道这样做会使黑客更容易一点。 将此值更改为更晦涩的值。

Also, a good rule of thumb to follow is to always perform a session_regenerate_id() call just before the redirect to any request to authenticate the users. This will ensure that the session ID is not the one provided by the attacker and help protect you from this situation.

同样，遵循的一个好的经验法则是始终在重定向到任何对用户进行身份验证的请求之前始终执行session_regenerate_id()调用。 这样可以确保会话ID不是攻击者提供的ID，并有助于保护您免受这种情况的侵害。

用户数据问题 (User Data Concerns )

If your site makes use of user data in any way then you have additional problems you need to keep an eye out for. First and probably foremost you want to think about the data traffic to and from the browser and server. This is an easy target many times, especially with so many people working on public open wireless networks. You might want to consider using an SSL connection (HTTPS for example) on your web site for all of your transactions. Even encrypting the database connection that PHP establishes may not be out of the question depending on the nature of your configuration.

如果您的站点以任何方式使用用户数据，那么您就需要注意其他问题。 首先，也许最重要的是，您要考虑往返浏览器和服务器的数据流量。 很多时候这是一个容易实现的目标，尤其是在如此众多的人使用公共开放无线网络的情况下。 您可能要考虑在网站上对所有事务使用SSL连接(例如HTTPS)。 根据配置的性质，即使对PHP建立的数据库连接进行加密也可能并非不可能。

Another thing to be concerned with in this area is the ability of an attacker to steal passwords from your database. This is slightly outside of the scope of this article since it deals mostly with how to encrypt your passwords so that they can’t be easily recovered using rainbow tables or other attack methods. I suggest checking out the article Why You Should Use Bcrypt to Hash Stored Passwords by Callum Hopkins for more information.

在这方面要考虑的另一件事是攻击者从数据库中窃取密码的能力。 这稍微超出了本文的范围，因为它主要处理如何加密密码，以使使用彩虹表或其他攻击方法无法轻松恢复密码。 我建议您查阅 Callum Hopkins的文章为什么您应该使用Bcrypt哈希存储的密码的文章， 以获取更多信息。

摘要 (Summary )

Is this all? I mean if you do everything in both this and my previous article will your site be secure? Yeah, sure. And keep all your money in a paper bag and carry it with you at all times.

这就是全部吗？ 我的意思是，如果您同时执行本文和上一篇文章中的所有内容，您的网站是否安全？ 当然可以。 并将所有金钱都放在纸袋中，并随时随身携带。

There are more ways to circumvent security than there are, well, than there are lots of other things. In the end, if you only do one thing, think suspiciously about ways that you could be vulnerable, and don’t trust any user input unless it is scrupulously scrubbed.

规避安全性的方法比其他很多方法还多。 最后，如果您只做一件事，请多想一想您可能会受到攻击的方式，并且不要信任任何用户输入，除非将它们仔细地清理掉了。

Yeah, I know that was two things. Do you get my point about not trusting people?

是的，我知道那是两件事。 您是否理解不信任别人的观点？

Image via Fotolia

图片来自Fotolia

翻译自: https://www.sitepoint.com/5-more-php-security-vulnerabilities/