受限eval函数漏洞：数组型$_REQUEST/$_SERVER能否被利用？

Great question—this is a super common edge case when dealing with restricted eval() setups, especially in PHP where these superglobals are almost always arrays by default. The short answer: yes, exploitation is still very possible—it all depends on how the restricted eval() interacts with these arrays. Let’s break down the most common attack paths:

1. Targeting Array Elements (The Most Common Vector) #

Most restricted eval() implementations don’t block the entire superglobal—they just check that the top-level variable is an array (instead of a directly injectable string). But if the code extracts and uses individual elements from $_REQUEST/$_SERVER inside the eval() call, you’re back in business.

For example, imagine this seemingly "safe" restricted code:

// Check that $_REQUEST isn't a string/integer
if (!is_array($_REQUEST)) {
    die("Blocked!");
}
// But still use an array element in eval
eval("handle_input('" . $_REQUEST['user_input'] . "');");

Here, you can just send a request with user_input set to something like '); malicious_code_here; //—the array check passes, but your injected string gets executed inside eval().

2. Exploiting PHP’s Array-to-String Conversion Quirks #

PHP automatically converts arrays to the string Array when you concatenate them with other strings. While this doesn’t directly execute code, it can break out of restrictive contexts if the eval() code is poorly structured.

Say you have code like this:

if (is_array($_REQUEST)) {
    eval("log_activity(" . $_REQUEST . ");");
}

This would render as log_activity(Array);—which throws an error on its own. But if you combine this with other flaws (like variable overwrite via extract($_REQUEST) elsewhere in the code), you can turn this error into a code execution path. For example, if you can overwrite a variable that’s used in the eval() call after the array conversion, you can inject malicious code.

3. Abusing Controllable String Values in $_SERVER #

Even though $_SERVER is an array, many of its elements are user-controllable strings—think $_SERVER['PHP_SELF'], $_SERVER['HTTP_X_FORWARDED_FOR'], or custom request headers. If the restricted eval() references any of these elements directly, you can inject code through those values, completely ignoring the fact that $_SERVER itself is an array.

4. Exploiting Array Key Injection #

If the restricted code iterates over the superglobal array (e.g., using foreach to assign variables), you can inject malicious code via array keys. For example:

foreach ($_REQUEST as $key => $value) {
    eval("\$config_$key = '$value';");
}

By setting a key like site_url'); phpinfo(); //, the eval() call becomes:

$config_site_url'); phpinfo(); // = 'some_value';

The injected code breaks out of the variable assignment and executes immediately.

Bottom Line #

Don’t assume arrays make a restricted eval() safe. The key is to look at how the code interacts with the array—whether it uses elements, converts the array to a string, iterates over keys, or references controllable string values inside the superglobal. All of these are potential exploitation points.

内容的提问来源于stack exchange，提问作者JohnDoes