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日：供应商发布了相应补丁，此漏洞被修复。