這篇文章主要為大家分析了如何深入理解$_REQUESTS數(shù)組的相關(guān)知識點(diǎn)，內(nèi)容詳細(xì)易懂，操作細(xì)節(jié)合理，具有一定參考價(jià)值。如果感興趣的話，不妨跟著跟隨小編一起來看看，下面跟著小編一起深入學(xué)習(xí)“如何深入理解$_REQUESTS數(shù)組”的知識吧。
十載的柳州網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都營銷網(wǎng)站建設(shè)的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整柳州建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“柳州網(wǎng)站設(shè)計(jì)”,“柳州網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
題目叫做詩，代碼如下：
漏洞解析：
這道題目包含了兩個(gè)漏洞，利用這兩個(gè)漏洞，我們可以往FTP連接資源中注入惡意數(shù)據(jù)，執(zhí)行FTP命令。首先看到 第7行代碼，可以發(fā)現(xiàn)程序使用 cleanInput方法過濾 GET、 POST、 COOKIE數(shù)據(jù)，將他們強(qiáng)制轉(zhuǎn)成整型數(shù)據(jù)。然而在 第8行處，卻傳入了一個(gè)從 REQUEST方式獲取的 mode變量。我們都知道超全局?jǐn)?shù)組 $_REQUEST中的數(shù)據(jù)，是 $_GET、 $_POST、 $_COOKIE的合集，而且數(shù)據(jù)是復(fù)制過去的，并不是引用。我們先來看一個(gè)例子，來驗(yàn)證這一觀點(diǎn)：
可以發(fā)現(xiàn) REQUEST數(shù)據(jù)絲毫不受過濾函數(shù)的影響。回到本例題，例題中的程序過濾函數(shù)只對 GET、 POST、 COOKIE數(shù)據(jù)進(jìn)行操作，最后拿來用的卻是 REQUEST數(shù)據(jù)，這顯然會(huì)存在安全隱患。想了解更多 $_REQUEST信息，大家自己上官網(wǎng)學(xué)習(xí)。第二個(gè)漏洞的話，在代碼 第21行，這里用了 ==弱比較。關(guān)于這個(gè)問題，我們在前面的文章中講的也很細(xì)致了，大家可以參考：[紅日安全]PHP-Audit-Labs題解之Day1-4 （Day4）。
至于本次案例的攻擊payload，可以使用： ?mode=1%0a%0dDELETE%20test.file，這個(gè)即可達(dá)到刪除FTP服務(wù)器文件的效果。
本次實(shí)例分析，我們分析的是 WordPress的 All In One WP Security & Firewall 插件。該插件在 4.1.4 - 4.1.9版本中存在反射型XSS漏洞，漏洞原因和本次案例中的漏洞成因一致，官方也在 4.2.0版本中修復(fù)了該漏洞。本次，我們將以 4.1.4版本插件作為案例講解。
將下載下來的插件zip包，通過后臺(tái)插件管理上傳壓縮包安裝即可。本次發(fā)生問題的文件在于 wp-content\plugins\all-in-one-wp-security-and-firewall\admin\wp-security-dashboard-menu.php，為了方便大家理解，我將問題代碼抽取出來，簡化如下：
我們可以很清晰的看到，問題就出在 第25行的 render_tab3方法中，這里直接將 REQUEST方式獲取的 tab變量拼接并輸出。而實(shí)際上，在 第20行已經(jīng)獲取了經(jīng)過過濾處理的 $tab變量。我們來看一下 get_current_tab方法：
過濾函數(shù)的調(diào)用鏈如下圖 第1行，接著 $tab變量就會(huì)經(jīng)過 wp_check_invalid_utf8方法的檢測。
下面我們來看看攻擊 payload（向 http://website/wp-admin/admin.php?page=aiowpsec&tab=tab3 POST數(shù)據(jù) tab="> ）：
可以看到成功引發(fā)XSS攻擊。我們最后再根據(jù) payload對代碼的調(diào)用過程進(jìn)行分析。首先，我們的 payload會(huì)傳入 wp-admin/admin.php文件中，最后進(jìn)入 第14行的 do_action('toplevel_page_aiowpsec');代碼。
在 wp-includes/plugin.php文件中，程序又調(diào)用了 WP_Hook類的 do_action方法，該方法調(diào)用了自身的 apply_filters方法。
然后 apply_filters方法調(diào)用了 wp-content\plugins\all-in-one-wp-security-and-firewall\admin\wp-security-admin-init.php文件的 handle_dashboard_menu_rendering方法，并實(shí)例化了一個(gè) AIOWPSecurity_Dashboard_Menu對象。
接下來就是開頭文章分析的部分，也就是下面這張圖片：
整個(gè)漏洞的攻擊鏈就如下圖所示：
這里還有一個(gè)小知識點(diǎn)要提醒大家的是，案例中 $_REQUEST["tab"]最后取到的是 $_POST["tab"]的值，而不是 $_GET["tab"]變量的值。這其實(shí)和 php.ini中的 request_order對應(yīng)的值有關(guān)。例如在我的環(huán)境中， request_order配置如下：
這里的 "GP"表示的是 GET和 POST，且順序從左往右。例如我們同時(shí)以 GET和 POST方式傳輸 tab變量，那么最終用 $_REQUEST['tab']獲取到的就是 $_POST['tab']的值。更詳細(xì)的介紹可以看如下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.
對于這個(gè)漏洞的修復(fù)方案，我們只要使用過濾后的 $tab變量即可，且變量最好經(jīng)過HTML實(shí)體編碼后再輸出，例如使用 htmlentities函數(shù)等。
看完了上述分析，不知道大家是否對 $_REQUEST數(shù)組有了更加深入的理解，文中用到的 CMS可以從這里( All In One WP Security & Firewall)下載，當(dāng)然文中若有不當(dāng)之處，還望各位斧正。如果你對我們的項(xiàng)目感興趣，歡迎發(fā)送郵件到 hongrisec@gmail.com聯(lián)系我們。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
關(guān)于“如何深入理解$_REQUESTS數(shù)組”就介紹到這了,更多相關(guān)內(nèi)容可以搜索創(chuàng)新互聯(lián)以前的文章，希望能夠幫助大家答疑解惑，請多多支持創(chuàng)新互聯(lián)網(wǎng)站！
