When including third-party functionality, such as a web widget, library, or other source of functionality, the software must effectively trust that functionality. Without sufficient protection mechanisms, the functionality could be malicious in nature (either by coming from an untrusted source, being spoofed, or being modified in transit from a trusted source). The functionality might also contain its own weaknesses, or grant access to additional functionality and state information that should be kept private to the base system, such as system state information, sensitive application data, or the DOM of a web application.

An attacker could insert malicious functionality into the program by causing the program to download code that the attacker has placed into the untrusted control sphere, such as a malicious web site.

Mitigation and prevention

Use the following strategies to help mitigate or prevent these issues:

Use a vetted library or framework that does not allow this weakness to occur or that provides constructs that make this weakness easier to avoid.
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and rejecting all other inputs.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules.
Store library, include, and utility files outside of the web document root, if possible.
Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls. Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.

Vulnerable code example

In this example, renderMenu is being used to render a menu for a page. The menu rendering is done by a javascript script whose location is passed as a parameter in a request. The method render of object menuRenderer is being called to perform the actual rendering.

An attacker could modify the parameter renderer in the request to have it point to a server under their control, loading a malicious script instead of the intended library. The code above would execute the render method on the malicious code, giving the attacker access to the context of the application.

1   public class MenuRenderer {
2   
3       public static void renderMenu(HttpServletRequest request) throws Exception {
4           ScriptEngineManager manager = new ScriptEngineManager();
5           ScriptEngine engine = manager.getEngineByName("JavaScript");
6   
7           //parameter "renderer" contains url of javascript rendering library
8           URL url = new URL(request.getParameter("renderer"));
9           engine.eval((String) url.getContent());
10  
11          Invocable inv = (Invocable) engine;
12  
13          // get script object on which we want to call the method
14          Object menu = engine.get("menuRenderer");
15  
16          // invoke the method named "render" on the script object "obj"
17          inv.invokeMethod(menu, "render", request.getParameter("menu"));
18      }
19  }

Fixed code example 1

In the fixed example, the input is sanitized.

1   public class MenuRenderer {
2   
3       public static void renderMenu(HttpServletRequest request) throws Exception {
4           ScriptEngineManager manager = new ScriptEngineManager();
5           ScriptEngine engine = manager.getEngineByName("JavaScript");
6   
7           //parameter "renderer" contains url of javascript rendering library
8           String cleanRenderer = sanitize(request.getParameter("renderer"));
9           URL url = new URL(cleanRenderer);
10          engine.eval((String) url.getContent());
11  
12          Invocable inv = (Invocable) engine;
13  
14          // get script object on which we want to call the method
15          Object menu = engine.get("menuRenderer");
16  
17          // invoke the method named "render" on the script object "menu"
18          inv.invokeMethod(menu, "render", request.getParameter("menu"));
19      }
20  }

Vulnerable code example 2

In this example, doGet trusts that the “dispatcher” parameter has not been tampered with and includes it in the response. An attacker could modify the parameter “dispatcher” to get the server to load a different file than intended, leading to an information leak, or elevated privileges (admin servlet).

1   void doGet(HttpServletRequest request, HttpServletResponse response) {
2     final String dispatcher = request.getParameter("dispatcher");
3     request.getRequestDispatcher(<source>).include(request, response);
4   }

Fixed code example 2

In the fixed example, the input is sanitized.

1   void doGet(HttpServletRequest request, HttpServletResponse response) {
2   	final String dispatcher = request.getParameter("dispatcher");
3   	if(isValid(dispatcher)){
4   		request.getRequestDispatcher(<source>).include(request, response);
5   	}
6   }

Related checkers

External guidance

CWE-829: Inclusion of Functionality from Untrusted Control Sphere

Extension

This checker can be extended through the Klocwork knowledge base by using @Check to specify methods that perform security checks or sanitize inputs. See Tuning Java analysis for more information.