如何深入理解$_REQUESTS数组

这篇文章主要为大家分析了如何深入理解$_REQUESTS数组的相关知识点，内容详细易懂，操作细节合理，具有一定参考价值。如果感兴趣的话，不妨跟着跟随小编一起来看看，下面跟着小编一起深入学习“如何深入理解$_REQUESTS数组”的知识吧。

十载的柳州网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都营销网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整柳州建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联从事“柳州网站设计”,“柳州网站推广”以来，每个客户项目都认真落实执行。

Day 16 - Poem

题目叫做诗，代码如下：

漏洞解析：

这道题目包含了两个漏洞，利用这两个漏洞，我们可以往FTP连接资源中注入恶意数据，执行FTP命令。首先看到 第7行代码，可以发现程序使用 cleanInput方法过滤 GET、 POST、 COOKIE数据，将他们强制转成整型数据。然而在 第8行处，却传入了一个从 REQUEST方式获取的 mode变量。我们都知道超全局数组 $_REQUEST中的数据，是 $_GET、 $_POST、 $_COOKIE的合集，而且数据是复制过去的，并不是引用。我们先来看一个例子，来验证这一观点：

可以发现 REQUEST数据丝毫不受过滤函数的影响。回到本例题，例题中的程序过滤函数只对 GET、 POST、 COOKIE数据进行操作，最后拿来用的却是 REQUEST数据，这显然会存在安全隐患。想了解更多 $_REQUEST信息，大家自己上官网学习。第二个漏洞的话，在代码 第21行，这里用了 ==弱比较。关于这个问题，我们在前面的文章中讲的也很细致了，大家可以参考：[红日安全]PHP-Audit-Labs题解之Day1-4 （Day4）。

至于本次案例的攻击payload，可以使用： ?mode=1%0a%0dDELETE%20test.file，这个即可达到删除FTP服务器文件的效果。

实例分析

本次实例分析，我们分析的是 WordPress的 All In One WP Security & Firewall 插件。该插件在 4.1.4 - 4.1.9版本中存在反射型XSS漏洞，漏洞原因和本次案例中的漏洞成因一致，官方也在 4.2.0版本中修复了该漏洞。本次，我们将以 4.1.4版本插件作为案例讲解。

将下载下来的插件zip包，通过后台插件管理上传压缩包安装即可。本次发生问题的文件在于 wp-content\plugins\all-in-one-wp-security-and-firewall\admin\wp-security-dashboard-menu.php，为了方便大家理解，我将问题代码抽取出来，简化如下：

我们可以很清晰的看到，问题就出在 第25行的 render_tab3方法中，这里直接将 REQUEST方式获取的 tab变量拼接并输出。而实际上，在 第20行已经获取了经过过滤处理的 $tab变量。我们来看一下 get_current_tab方法：

过滤函数的调用链如下图 第1行，接着 $tab变量就会经过 wp_check_invalid_utf8方法的检测。

漏洞利用

下面我们来看看攻击 payload（向 http://website/wp-admin/admin.php?page=aiowpsec&tab=tab3 POST数据 tab="> ）：

可以看到成功引发XSS攻击。我们最后再根据 payload对代码的调用过程进行分析。首先，我们的 payload会传入 wp-admin/admin.php文件中，最后进入 第14行的 do_action('toplevel_page_aiowpsec');代码。

在 wp-includes/plugin.php文件中，程序又调用了 WP_Hook类的 do_action方法，该方法调用了自身的 apply_filters方法。

然后 apply_filters方法调用了 wp-content\plugins\all-in-one-wp-security-and-firewall\admin\wp-security-admin-init.php文件的 handle_dashboard_menu_rendering方法，并实例化了一个 AIOWPSecurity_Dashboard_Menu对象。

接下来就是开头文章分析的部分，也就是下面这张图片：

整个漏洞的攻击链就如下图所示：

这里还有一个小知识点要提醒大家的是，案例中 $_REQUEST["tab"]最后取到的是 $_POST["tab"]的值，而不是 $_GET["tab"]变量的值。这其实和 php.ini中的 request_order对应的值有关。例如在我的环境中， request_order配置如下：

这里的 "GP"表示的是 GET和 POST，且顺序从左往右。例如我们同时以 GET和 POST方式传输 tab变量，那么最终用 $_REQUEST['tab']获取到的就是 $_POST['tab']的值。更详细的介绍可以看如下PHP手册的定义：

request_order string
This directive describes the order in which PHP registers GET, POST and Cookie variables into the _REQUEST array. Registration is done from left to right, newer values override older values.

If this directive is not set, variables_order is used for $_REQUEST contents.

Note that the default distribution php.ini files does not contain the 'C' for cookies, due to security concerns.

修复建议

对于这个漏洞的修复方案，我们只要使用过滤后的 $tab变量即可，且变量最好经过HTML实体编码后再输出，例如使用 htmlentities函数等。

结语

看完了上述分析，不知道大家是否对 $_REQUEST数组有了更加深入的理解，文中用到的 CMS可以从这里( All In One WP Security & Firewall)下载，当然文中若有不当之处，还望各位斧正。如果你对我们的项目感兴趣，欢迎发送邮件到 hongrisec@gmail.com联系我们。Day16的分析文章就到这里，我们最后留了一道CTF题目给大家练手，题目如下：

// index.php
>24 == $int_ip>>24 || ip2long('10.0.0.0')>>24 == $int_ip>>24 || ip2long('172.16.0.0')>>20 == $int_ip>>20 || ip2long('192.168.0.0')>>16 == $int_ip>>16 || ip2long('0.0.0.0')>>24 == $int_ip>>24;
}

function safe_request_url($url)
{
    if (check_inner_ip($url)){
        echo $url.' is inner ip';
    }
    else{
        $ch = curl_init();
        curl_setopt($ch, CURLOPT_URL, $url);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($ch, CURLOPT_HEADER, 0);
        $output = curl_exec($ch);
        $result_info = curl_getinfo($ch);
        if ($result_info['redirect_url']){
            safe_request_url($result_info['redirect_url']);
        }
        curl_close($ch);
        var_dump($output);
    }
}

$url = $_POST['url'];
if(!empty($url)){
    safe_request_url($url);
}
else{
    highlight_file(__file__);
}
//flag in flag.php 

?>

// flag.php

关于“如何深入理解$_REQUESTS数组”就介绍到这了,更多相关内容可以搜索创新互联以前的文章，希望能够帮助大家答疑解惑，请多多支持创新互联网站！

分享标题：如何深入理解$_REQUESTS数组
文章位置：http://6mz.cn/article/ihoggo.html