Similar to the file:// scheme used in the earlier example, the PHP interpreter also provides access to various input and output streams via the php:// scheme. This makes sense for when PHP is used in a command-line interface (CLI) and the developer needs to access these common operating system standard streams: stdin, stderr, stdout, and even the memory. Standard streams are used by applications to communicate with the environment they are executing in. For example, the Linux passwd will utilize the stdout stream to display informational messages to the terminal ("Enter your existing password"), stderr to display error messages ("Invalid password"), and stdin to prompt for user input to change the existing password.
The traditional way to parse input coming in from a web client is to read data using the $_GET and $_POST superglobals. The $_GET superglobal provides data that is passed in via the URL, while the $_POST superglobal contains the POST body data, neatly parsed.
Note
A superglobal is a variable that is always set by the PHP interpreter and is accessible throughout the application. $_GET and $_POST are the most popular, but there are others, including $_SESSION, $_ENV, and $_SERVER. More information can be found in the PHP manual: http://php.net/manual/en/language.variables.superglobals.php.
In a file inclusion vulnerability, the php:// scheme can be leveraged alongside the input (aka stdin) stream to attack the application. Instead of accessing a resource over the common http:// or https://, the php://input URL can be included in the application to force PHP to read the request body as if it were code and execute it. The input data is retrieved by the interpreter from the body of the request.
If we pass in the php://input value as the included page and in the body of the request we enter arbitrary PHP code, the server-side interpreter will read it and execute it, as shown in the following figure:
Figure 5.10: Executing PHP code using LFI
The GET request shown in the preceding screenshot, in the left page, uses the php://input as the page parameter, instructing PHP to include code coming in from user input. In a web application setting, input data comes from the body of the request. In this case, the body contains a simple PHP script that executes the command cat /etc/passwd on the system. The response reflects the output of /etc/passwd, confirming that remote code execution was successful.
No external connections are made and the network-based egress whitelist control has been bypassed. PHP is a feature-rich programming language and there are many ways to accomplish the same thing. This is usually a good thing for attackers, as it provides more opportunity for control bypass, obfuscation, and data exfiltration. This statement is true not only for PHP but other languages as well.