对我来说，这听起来像是在告诉永远不要开车的人，这样他们就不会发生车祸。我的直觉是主机试图将责任归咎于客户端自身系统中的安全漏洞。另外，无论我们是否使用它，服务器仍然安装了PHP，因此我在质疑这实际上减少了多少攻击面...但是由于我不是安全专家，所以我不想坚持
我告诉我的客户，要处理联系表单，他们将需要某种形式的动态脚本。 （错误？）他们问我是否可以只在那一页上使用PHP。这样测量是否更安全，或者等同于锁上车门并使窗户滑下？
使用任何PHP脚本，无论多么简单，是一个固有的安全问题？我们在没有SSL的共享主机上。假设我们由于使用PHP而被黑客入侵是否合理？如果不使用它，但无法将其卸载，我们会更安全吗？因为如果没有，我们还有其他问题。
（答案是否会和其他语言一样？）
#1 楼
PHP本身并没有安全问题（假设需要安全更新），因为它存在很多流行的基于PHP的软件，都存在严重的安全问题。您可能会指责PHP是一种能够给您足够的绳索来使自己窒息的语言，但真正的问题是易受攻击的PHP代码实际上是多么普遍。一个人只需要使用Stack Overflow PHP标记就可以找到基于新旧教程的残酷脚本编写PHP的新手。缺陷基于非常古老的代码和编码实践。由于固有的安全性问题，许多这些旧做法被认为是不当做法。对我来说，这听起来像是在告诉某人不要开车，以免他们开车上车。意外。
是的。更好的建议可能是“不要在没有安全气囊的情况下驾驶旧车”。
我的直觉是房东试图将责任推卸给客户，以确保安全自身系统中的缺陷。
不一定。如果用户为WordPress网站和cPanel使用相同的密码，则破坏WordPress密码也会损害cPanel。那将是用户的错。黑客很少需要走那么远，而只需使用PHP shell。
我告诉我的客户，要处理联系表单，他们将需要某种形式的动态脚本。 （假？）
不一定正确。您可以使用第三方服务来处理邮件发送。然后，该服务将处理动态服务器脚本并接管安全隐患。有许多这样的服务，它们具有不同的功能集，它们很受欢迎，可以为静态生成的站点上的联系表单提供动力。声称使用任何PHP脚本（无论多么简单）是一个固有的安全问题，这有多少道理呢？ PHP确实在PHP和执行它的服务器软件中都包含一些活动代码。如果该过程中曾经存在不依赖于特定PHP代码的安全漏洞，则可以利用该漏洞。虽然这种风险很小，但是这是没有这种支持的服务器所没有的风险。
评论
评论不作进一步讨论；此对话已移至聊天。
–Rory Alsop♦
16年7月1日在11:26
#2 楼
“正确”可能不是正确的词，但是会想到“明智”，“谨慎”和“尽责”。自成立以来，PHP一直坚持降低软件正确性的理念。程序可能会遇到很多情况，其他语言（例如Python）会放弃并抛出错误以告诉您您的程序是错误的，但是PHP却选择做一些荒谬的事情并继续进行，就像事情只是很好。请记住，正确性对于安全性非常重要。倾向于静默忽略左右错误的语言将比带有安全问题的程序拥有更多的份额。例如，您可能有一段代码，您的程序员认为该代码可以防止某种攻击，但实际上由于解释程序忽略错误而被跳过。
另外：
PHP旨在吸引程序员的最低分母，并以最少的动机来提高自己的技能。因此，最有可能编写不安全的软件。
PHP团队在解决常见的安全问题方面存在着严重的缺陷。例如看一下SQL注入保护，它出卖了反复的错误尝试来解决问题：
real_escape_string（因为原始的escape_string已损坏，但是直到后来他们才将其删除）与addslashes和mysql_escape_string / pg_escape_string等等。几乎所有其他语言都带有准备好的语句和查询参数，并且在第一次尝试时就具有可扩展到所有数据库的设计。 PHP中的软件，如果您尝试使用它，将会非常不符合潮流。评论
评论不作进一步讨论；此对话已移至聊天。
–Rory Alsop♦
16年7月6日在19:32
#3 楼
一般而言，PHP的安全性问题可以分为两类：未打补丁的系统
截至目前，Wordpress统计数据显示，超过一半的用户都在生命周期结束的PHP版本上运行PHP（PHP 5.2 -5.4）。在两周内，PHP 5.5停产，然后跃升至所有安装量的80％。公平地说，现在，某些Enterprise / LTS Linux安装将向后移植安全修复程序，但其中绝大部分都未使用向后移植的修复程序（或某些未对其系统进行修补）。更糟糕的是，许多人拒绝升级PHP本身。他们要么无法/不会更新其代码，要么他们认为较旧的软件更稳定。软件本身（他们已经取得了长足的进步），但是尽管如此，只有40％的用户运行的是最新版本的Wordpress。这意味着大约60％的人可能存在未修补的安全漏洞。那只是基础程序。 WordPress具有庞大的插件生态系统，其中许多都有自己的安全漏洞。
然后还有其他问题，例如使用已失效的mcrypt库的许多旧代码。那只是您可以编译的一个PHP插件。
现在将其推断为未运行的服务器，并将统计信息报告给WP。它没有画出漂亮的图画。去年夏天，我发现一个运行电子商务页面的网站仍在Apache 1.3.3和PHP 4.1.2上。它太老了，启用了SSLv2。...
错误做法
如果您对SO PHP问题的讨论时间足够长，就会发现很多人在练习错误代码。我多年来看到的一些问题
SQL注入
认为MD5是保护密码的好方法
在代码中使用过时的API（例如， MySQL连接器）
信任用户输入以执行代码（即对用户提供的数据使用eval）
不关闭PHP代码中的安全风险（即exec函数）
对于未经培训的人来说，这似乎是一个PHP问题，这是由编码人员及其生态系统引起的。也许他们很着急。也许他们雇了一个在业余时间做这件事的人，“只是让它起作用”。
可以安全吗？但是，这种安全性需要付出一些努力。使您的PHP安装保持最新。哎呀，让您的整个服务器保持最新状态。主机不会做安全和补丁程序吗？查找其他主机。 （对此感到惊讶的人感到惊讶）。构建自己的服务器（VM很便宜）。但首先要注意。了解有关安全性的所有知识。不要只是让您的网站和服务器出海。
告诉您PHP不安全的人只是在偷懒。
评论
构建自己的服务器（VM很便宜）。 -仅当您知道如何管理Linux机器，或者（适当地）为您完成了管理时，才执行此操作。拥有虚拟机的人本身不知道如何合理地使它们保持安全是一个重大问题。
– marcelm
16年6月28日在20:15
@marcelm True，但是至少您可以使用自己的VM，而不是不会升级任何内容的主机
–Machavity
16年6月28日在20:45
从安全角度来看所有语言都是平等的想法是错误的。说您可以解决问题并不等于没有问题的语言，或者要求您积极介绍这些问题。
– JimmyJames
16年6月28日在21:11
“告诉您PHP不安全的人只是在偷懒。” ->我完全同意！
–乔西普·伊维奇（Josip Ivic）
16年6月29日在9:30
“告诉您PHP不安全的人只是在偷懒”：或者对即将发生的懒惰感到现实。我的意思是，也可以在原始汇编器中编写一个安全的网站，但实际上这很可能不会发生。
–ruakh
16年6月29日在23:09
#4 楼
与其他任何语言（Java，Rails等）相比，PHP都是一样，或更安全或更不安全。这全都与编码有关。是否进行制衡，以偏转，防御，防止或减轻攻击。引用：WhiteHat Security使用.NET，Java，ASP，PHP，Cold Fusion和Perl对30,000多个网站进行了漏洞评估。
最广泛使用的语言是.NET（占Web
应用程序的28.1％），Java（占24.9％）和ASP（占15.9％）。
...
编程语言.Net每个插槽，Java 11.32和ASP 10.98平均具有11.36个漏洞。最安全的语言
ColdFusion，每个插槽有六个漏洞。 Perl每个插槽有七个漏洞，而PHP有10个漏洞。
...
Java占发现的漏洞的28％，ASP占15％ 。报告说：“同样，必须考虑使用语言
编写的应用程序的数量以及网站的复杂性。” PHP还占发现的漏洞的15％。 ColdFusion仅占漏洞的4％，而Perl仅占漏洞的2％。 （源）
这并没有说明如何根据良好的编码惯例来开发网站。例如，如果您使用每种语言的非熟练（缺乏术语）程序员，则这些数字可能会相反，而perl的漏洞最多，而.Net的漏洞最少。一切都归结为代码本身应该做什么。在将代码投入开发之前，是否已对其进行编程以执行其唯一功能并进行了篡改/滥用测试？有很多安全备忘单，最佳实践指南和其他涉及安全问题的文章，但是在这种情况下，客户会根据提供者的建议而感到厌烦。她说，要说服您的客户允许您使用PHP创建网站，这可能是一个障碍，因为这变成了“他说”。如果我仍然想使用PHP，我可能会使用的一种方法是创建一个演示站点，然后对它使用漏洞评估扫描程序（Acunetix，AppScan，Burpsuite）检查缺陷。如果找不到任何内容，我将向该报告提供详细说明您对两个客户端构建的安全状态的报告，并以可以提供给提供者的方式（PDF等）创建。
评论
.Net不是一种编程语言。...该文章信誉良好吗？
–BalinKingOfMoria恢复CM
16年6月28日在19:51
@BalinKingOfMoria，当有人在编程语言的上下文中说“ .Net”时，他们通常是指带有.Net / CLR运行时的C＃。有时，他们指的是带有.Net / CLR运行时的Visual Basic.NET。
–马克
16年6月28日在20:48
因此，在您参考的报告中，它说11％的站点是PHP，但是发现的漏洞中有15％。如果您假设漏洞应该在各种语言之间平均分配，那代表的数量将超出您预期的36％。 Java和.NET在漏洞中所占的比例也很高，但分别仅为12％和11％。按照该指标，PHP在该报告中具有（到目前为止）最差的统计信息。
– JimmyJames
16-6-29在16:24
对我来说，这个答案就像是说所有汽车都一样安全，只是指关节驾驶员就是问题所在！我认为谈论一种语言本质上是不准确的，而不是谈论很难发现该种语言的错误。 PHP的类型很弱，这会导致犯其他语言永远不会犯的错误。本质上，该语言允许您犯这些错误。把所有的责任都放在开发人员上来编写完美的代码是一个错误，并且说这纯粹是一个编码问题会错了重点。编码器和语言很难分开。
– Steve Sether
16年6月29日在21:40
有趣的是，PHP站点“没有像.NET或Java站点那样大或复杂的趋势，但仍然遭受许多相同的问题困扰”。因此，基本上，尽管PHP站点明显更简单和复杂程度较低，但其漏洞与更复杂的.NET或Java站点一样多。这就像注意到一百万个LOC应用程序具有与100k LOC应用程序相似的绝对错误数，然后得出结论，两者的质量相似。
– Voo
16年6月29日在22:02
#5 楼
PHP的基本问题之一实际上是CGI事物模型的基本问题（尽管存在mod_php的陷阱，PHP还是基于CGI的）-即面向用户的数据与脚本混合在一起，例如，它变得非常容易。用户上传成为可执行脚本。这并不是PHP本身的问题，但在系统上完全可以使用PHP使其成为一个很大的攻击面。例如，相当多的WordPress插件的安全性问题就来自此方面。传统的基于CGI的部署在历史上通过仅允许CGI脚本从受信任的目录（例如
/cgi-bin/）运行来缓解此问题），但许多共享主机提供商最终放宽了对“方便”的限制，并且在整个PHP中也普遍存在这种便利。许多基于PHP的现代应用程序经常将
.htaccess用作快速而又肮脏的请求路由机制确实有助于缓解这些问题，但这远非通用，而且仍然不是很容易解决。在我看来，PHP的最大问题在于它是如此容易任意PHP代码都可以在配置了该代码的任何服务器上执行，因此，用PHP编写的代码不一定比使用其他语言编写的代码更安全或更不安全（尽管其标准库在以下情况下并不能提供任何帮助）涉及编写安全代码）， PHP脚本执行的一种机制通过PHP的优点提出了巨大的安全挑战，甚至在服务器上也是如此。
#6 楼
我同意您的评估，即使用PHP并不一定会带来安全风险。有些供应商出于与WordPress被视为安全风险的原因大致相同，而放弃了PHP。很受欢迎越是普遍的东西，就越多地将精力投入到开发漏洞利用程序上。活动。底线：安全风险是与平台无关的安全风险。更改脚本语言不会减轻与编写/开发/实施代码不当相关的安全风险。评论
WordPress是一种安全风险。即使是内核，也具有可怕的编码实践和悠久的漏洞历史。
–雅科
16年6月28日在19:38
@Jacco是的，但是很多应用程序的肠子里都有不好的代码。 WordPress主要是针对性的，因为它很流行。在最近的几次迭代中，该内核进行了一些改进，尽管还远远不够完善。
–哈希危害
16年6月28日在19:42
命名一个没有悠久历史的流行应用程序/系统。哦，是的，android
– Claudiu Creanga
16年7月2日在18:42
@ClaudiuCreanga真的吗？ android是您要用作没有长期漏洞历史的系统的示例吗？
–蓬松
16年7月4日在19:40
#7 楼
如果只想包含一个标准的页眉/页脚，则PHP可能会过时-简单的服务器端包含可以做到这一点。但是，如果您在服务器上不需要完整的脚本语言，则最佳安全做法是不安装一种。如果您说过无论如何都要在服务器上安装PHP，那么只要您不做任何愚蠢的事情，使用它所产生的额外风险大约为零。除非您以某种方式从URL参数解析文件名，否则包含模板就不是愚蠢的。这部分内容将成败的关键在于-无论使用哪种语言，如果是SQL数据库，那么SQL注入就值得关注；如果以某种方式将用户的输入回显到用户或网页中的客户端，则需要考虑（java）script注入，并且所有内容均应正确转义为HTML。与联系表相比，使用include会尽可能安全。如果您只想要一组网页，而不是交互式Web应用程序，则最终的安全性是使用静态网站生成器-服务器只需要提供文件即可，从而大大减少了攻击面。
因此：
声称使用任何PHP脚本（无论多么简单）都是固有的安全性问题有多少道理？
这样说，几乎没有。包含标头脚本当然不是漏洞。不需要时首先安装PHP并不是最佳安全实践，安装并在安全补丁发布时不定期对其进行更新是一个潜在的问题，因为没有负责这些更新的人的政策-完成网站设计后，客户将负责此工作吗？还是托管服务提供商？如果客户端对此感到担心，那么他们首先不应该在服务器上安装PHP。如果不是这样，那么就没有安全相关的理由不在知道您正在做什么的地方使用它。
评论
“在不需要的时候首先安装PHP并不是最佳的安全实践，安装并在安全补丁发布时不定期对其进行更新是一个潜在的问题” ...担心！不幸的是，它是共享主机，因此在这方面没有太多选择。 ：/我必须详细了解服务器端包含，谢谢！
– Yumecosmos
16年6月28日在17:57
@Yumecosmos如果是共享托管，则托管服务的其他租户要比PHP本身承担更大的风险。共享主机通常不愿意为众多（有时数千个）租户之一安装某些设备，并且会提出各种理由来避免这种情况。一个简单的“您正在共享主机上，您所看到的就是您所得到的”会更加诚实（并且完全公平）。
–ceejayoz
16年6月28日在18:27
@ceejayoz到此为止，几乎每次我的网站被黑客入侵时，都是通过同一矢量共享主机上的另一个网站。但是，绝对可以采取一些措施来限制这种可能性，例如，非常注意文件权限等。我有一个每晚的cron作业，可验证我的文件权限并检测我所有文件和其他一些东西上的md5sum更改。
–蓬松
16年6月30日在18:08
#8 楼
语言和工具并不是天生就没有安全感，也不是错误的代码和安全实践。决定。这不是工具，而是使用它的猴子；-)
用任何语言编写的代码都不安全。
评论
语言可能并非天生就具有不安全性，但是它们在设计中可能具有深深的根基。 PHP并非如此，这是一种轻描淡写的说法。参见eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design
–通配符
16年6月30日在5:01
这就是每个人都应该学习Python的原因！抱歉，“另一种语言很烂，所以学习Python！”网站格式错误。您也可以在Python中编写垃圾。我已经修好了很多。对于能力不强的程序员来说，Python并不是灵丹妙药。您使用您的雇主已标准化的语言编写代码，或者在我的情况下，根据客户的要求编写代码。我不知所措。我使用Python，php，Java，.net，Perl进行编码，甚至维护一些旧的冷融合站点。请不要劫持帖子以推动Python议程。
–尼尔·戴维斯（Neil Davis）
16年6月30日在12:05
我没有在任何地方提到Python。我什至还没学过Python（尽管我要学习）。以常识的名义，您如何将我先前的评论解释为“推动Python议程”令人困惑。但是您在这里的答案基本上等于“没有一种语言比任何其他语言都更安全”，这是胡说八道。 （此答案提供了有关原因的一些细节。）
–通配符
16年6月30日在17:59
您提供了指向狂热的Python福音派观点的链接
–尼尔·戴维斯（Neil Davis）
16年6月30日在18:05
@ user356540 eevee关于Python的第一件事说：“我爱上了Python。如果您真的想要我，我也会很高兴地谈论您的抱怨。我并不是说它是完美的；我只是权衡了它的好处针对它的问题并得出结论，它最适合我想做的事情。”那与狂热的Python传播者不同。
–蓬松
16年6月30日在18:10
#9 楼
“他们不愿意，因为托管公司告知他们使用PHP是一种安全问题，这可能会使某人闯入cPanel并获得对该网站的控制权”如果托管公司认为他们需要cPanel运行PHP，然后是时候移动主机了
评论
评论不作进一步讨论；此对话已移至聊天。