phpbb,PhpBB3 收藏 0

PHP最新统计数据公布：市场份额77.2%，仍是“首选编程语言”

IT之家 9 月 11 日消息，Wikimedia 基金会首席工程师 Timo Tijhof 日前发文，透露了 PHP 语言的使用数据，并强调了 PHP 语言对于互联网的作用，IT之家整理相关内容如下：

Timo Tijhof 从 W3 Techs 发布的《全球前 1000 万个网站使用的编程语言分析（截至 2023.8）》中，摘录得出这一结果，其中：

• PHP 占比 77.2%

• ASP 占比 6.9%

• Ruby 占比 5.4%

▲ 图源 timotijhof.net

绝大多数公开网站都是使用基于 PHP 的 CMS 进行构建，12 大 CMS 软件中有 8 个采用 PHP 编写，同样基于上述 W3 Techs 的分析结果，每个百分点代表前 1000 万个网站中的 10 万网站。

• [PHP] WordPress 生态（63%）

• [Ruby] Shopify

• Wix

• Squarespace

• [PHP] Joomla 生态 （3%）

• [PHP] Drupal 生态（2%）

• [PHP] Adobe Magento（2%）

• [PHP] PrestaShop（1%）

• [Python] Google Blogger

• [PHP] Bitrix（1%）

• [PHP] OpenCart（1%）

• [PHP] TYPO3（1%）

▲ 图源 timotijhof.net

根据 BuiltWith 2023 年 8 月对在线商店的报告，可以看到 PHP 在电商领域仍然占“统治地位”：

• 使用了 WooCommerce 插件的 WordPress 网站（全球市场份额 24%）

• Adobe Magento（全球市场份额 7%）

• OpenCart（全球市场份额 2%，俄罗斯市场份额 24%）

• PrestaShop （全球市场份额 2%，法国市场份额 14%）

• Shopware（全球市场份额 1%，德国市场份额 12%）

▲ 图源 timotijhof.net

Timo Tijhof 同时引用 Ars Technica 的图表数据，认为“PHP 依然保持着巨大的领先优势”。

▲ 图源 timotijhof.net

Slack 公司首席架构师 Keith Adams 表示，Slack 大部分服务器端的应用程序逻辑采用 PHP 编写。相对于 PHP 的优势（通过故障隔离降低错误成本；安全并发；以及高吞吐量），其存在的问题可以忽略不计。

▲ 图源 timotijhof.net

Vimeo 工程师表示，Vimeo 在 PHP 方面的持续成功证明，PHP 对于 2020 年快速发展的公司来说是一个很棒的工具。

▲ 图源 timotijhof.net

Timo Tijhof 同时从 W3 Techs 的报告中得出，业务比较单一的公司中，规模最大的是 WordPress，它驱动着 Automattic 的 WordPress.com，每月有 200 亿 PV（Alexa 全球排名 55）。

再进一步了解，看看占市场份额 0.1% 的条目，可以看到大量网站都是靠 PHP 系统来支撑的，PHP 仍然是超过 10 万小网站的首选框架。

• #23 CMS：Moodle

• #25 CMS：phpBB，例如 Google 的 Waze 社区、ApacheFriends 论坛、VideoLAN 论坛

• #31 CMS：XenForo 论坛，例如 ArsTechnica.com 和 MacRumors.com

• #33 CMS：Roundcube

• #45 CMS：MediaWiki

• #49 CMS：vBulletin 论坛

• #53 CMS：IPS 社区，例如 MalwareBytes.com、BleepingComputer 和 Squarespace.com 论坛

MediaWiki 驱动着维基百科以及大量第三方百科，每月有 250 亿 PV（Alexa 排名 12），同时 MediaWiki 还驱动着 Fandom（每月有 20 亿 PV，Similarweb 排名 44）和 WikiHow（每月有 1 亿访问者，Alexa 排名 215）。

除此之外还有一大批互联网公司采用 PHP 技术栈，例如 Facebook（Alexa 排名 7）、Etsy（Alexa 排名 66）、Vimeo（Alexa 排名 165）和 Slack（Similarweb 排名 362）。

Timo Tijhof 据此，认为 PHP 当前依然具有独特的优势，“其有一个庞大的生产力社区，积极的开发者，易于学习，易于扩展”，因此在当下依然有不可撼动的地位。

phpBB管理控制面板代码中惊现CSRF漏洞

不久之前，我在phpBB中管理控制面板的实现代码中发现了一个CSRF(跨站请求伪造)漏洞，值得一提的是，这段代码是以BBCode风格开发的。phpBB的开发团队于2016年1月11日发布了phpBB 3.1.7-PL1，并在这个版本中修复了我之前所发现的那个CSRF漏洞。由于BBCode会将管理员所创建的HTML页面自动列入网站的白名单之中，这个CSRF漏洞便能够允许攻击者向论坛帖子中注入任意的HTML代码或者JavaScript代码了。

这是我第一次对phpBB进行研究，整个过程只花费了我几个小时的时间，而在这几个小时之内我便发现了一些影响非常大的问题，我对此感到非常的欣慰。

phpBB是一个论坛软件，该项目使用PHP语言进行开发，并开源了该项目的原始代码。phpBB采用模块化设计，具有专业性、安全性、支持多国语系、支持多种数据库和自定义的版面设计等优越性能，而且功能十分的强大。除此之外，它还具有很高的可配置性，用户完全可以利用这个系统定制出相当个性化的论坛。

查找攻击目标

如果大家想要进一步了解phpBB的实际功能，并且了解phpBB控制器的运行机制，那么大家应该对phpBB的内部文件结构进行深入学习，并且理解phpBB控制器所进行的复杂操作。./phpbb/phpbb/posting.php是一个非常合适的切入点，因为当用户在论坛的某一话题板块中发表帖子时，便会使用到这个文件。从理论上来说，这个控制器应该能够进行权限检测，创建记录，表单提交等操作，有时也应该能够处理HTML代码的转义。在这个文件的头部，我们可以看到一些有趣的内容：

?

1

2

3

4

5

6

7

8

9

10

11

// 在此我们只提取了部分有用的参数

$post_id = request_var(\’p\’, 0);

$topic_id = request_var(\’t\’, 0);

$forum_id = request_var(\’f\’, 0);

$draft_id = request_var(\’d\’, 0);

$lastclick = request_var(\’lastclick\’, 0);

$preview = (isset($_POST[\’preview\’])) ? true : false;

$save = (isset($_POST[\’save\’])) ? true : false;

$load = (isset($_POST[\’load\’])) ? true : false;

$confirm = $request->is_set_post(\’confirm\’);

$cancel = (isset($_POST[\’cancel\’]) && !isset($_POST[\’save\’])) ? true : false;

这个控制器所需要使用的参数和变量基本上都在文件头部进行了声明和定义，还有一部分变量是通过request_var函数(多么奇怪的一个函数啊)来调用的，但是IntelliJ却告诉我这个函数目前已经弃用了。

这个函数是用来对\\phpbb\\request\\request_interface::variable进行封装的。在对\\phpbb\\request\\request::variable进行了分析之后，我发现这个方法可以从某些联合数组中取出函数所请求的变量，并将它们返回给调用函数。这种数组是$_POST和$_GET访问全局变量之间的级联。如果你并不了解PHP编程语言，那么我得说的更加详细一些。这些全局变量都包含有POST请求以及分别查询变量的能力。系统会对所有的这些变量进行处理，这些变量也将会与默认值的类型相匹配。

有一点非常的关键：如果我们能够在论坛中找到发起POST请求的地方，那么我们同样可以使这个请求通过GET方法来进行发送。那么现在，我们是不是应该开始对这个CSRF漏洞进行分析了？

phpBB中CSRF令牌的工作机制

利用IDEA，我在文件中搜索“form”字段，然后得到了下列信息：

if ($submit && check_form_key(\’posting\’))

接下来，我对check_form_key函数进行了分析。很明显，这个函数就是执行CSRF令牌检测的函数，但是这一操作却需要手动完成。在文件的下方，我还发现了：

add_form_key(\’posting\’);

就此看来，添加和检测CSRF令牌的操作是要手动去完成的。这一机制听起来似乎迟早会发生错误的!

找到CSRF漏洞!

现在，我们在整个项目中搜索add_form_key和check_form_key。在这一步骤中，我们期望找到的文件能够显示出add_form_key函数的执行结果，而不是check_form_key的结果。

下面这张图片显示的是我们分别搜索add_form_key和check_form_key的查找结果，基本上都在phpBB中管理控制面板的实现代码之中：

系统对check_form_key函数和add_form_key函数进行了大量的调用，但是这些并不重要，因为你想对表单的key进行多少次检测都可以。我们正在查找的是在整个phpBB项目中，什么地方会直接添加一个没有进行验证的表单key。我们发现了两个文件，这两个文件本该调用check_form_key函数来对表单key进行检测，但实际上并没有：

acp_bbcode.php

acp_extensions.php

acp_extensions.php并没有什么有趣的地方，因为只有管理员在对论坛系统进行扩展和更新时，才会使用到这个文件。这个文件能够在管理员检测更新时，显示出相关插件或者系统更新的开发版本(即不稳定版)。所以这是一个非常严重的CSRF漏洞，攻击者可以利用这一机制来欺骗论坛系统的管理员，并让管理员认为论坛所使用的插件已经过期了。

相比之家，acp_bbcode.php就有趣多了，尽管系统会使用POST方法来提交表单信息，但同时还会使用 request_var方法来获取所有的表单变量。这样一来，我们应该能够在不使用CSRF令牌的情况下开发出相应的BBCode代码了。

注意事项

尽管从理论上来说，这一漏洞能够引起XSS攻击(跨站脚本攻击)，但实际可行性并不高。phpBB在默认配置下会为管理员分配不同的CP会话ID。在默认情况下，这个ID会显示在cookie和查询字符串之中。

从理论上来说，攻击者是可以在系统对会话ID进行检测的过程中(系统会使用等号运算符来进行检测：$this->session_id !== $session_id)发动攻击的，但是这种方法实际上可行性也并不高，因为这些会话操作是与IP地址，浏览器，以及其他的一些信息绑定在一起的。但最重要的一点就是，利用这种方法来通过网络发动攻击是非常困难的。

目前为止，这是我所发现的唯一一个可行的攻击方法：如果系统中的某些管理页面还存在XSS漏洞，那么攻击者就可以向漏洞页面注入相应的脚本代码，然后从页面的document.location中获取到管理员的SID，这样就可以利用这个CSRF漏洞了。

时间轴

2015年7月11日：报告漏洞的信息;

2015年8月4日：该项目的两名开发人员给予了回应，并希望我提交有关漏洞的详细信息;

2015年12月23日：跟进漏洞处理进展(我一直都没有收到通知，我都差不多把这件事情给忘了);

2015年12月23日：供应商确认了这个漏洞;

2016年1月11日：供应商发布了相应补丁，此漏洞被修复。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com