1745
significantly reduces the chance of an attacker being able to bypass any protection mechanisms
that are in the base program but not in the include files. It will also reduce the attack surface.
Phase: Architecture and Design
Phase: Implementation
Strategy = Attack Surface Reduction
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.
Phase: Operation
Strategy = Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial
in cases in which the code cannot be fixed (because it is controlled by a third party), as an
emergency prevention measure while more comprehensive software assurance measures are
applied, or to provide defense in depth.
Effectiveness = Moderate
An application firewall might not cover all possible input vectors. In addition, attack techniques
might be available to bypass the protection mechanism, such as using malformed inputs that can
still be processed by the component that receives those inputs. Depending on functionality, an
application firewall might inadvertently reject or modify legitimate requests. Finally, some manual
effort may be required for customization.
Demonstrative Examples
Example 1:
This login webpage includes a weather widget from an external website:
Example Language: HTML (Bad)
<div class="header"> Welcome!
<div id="loginBox">Please Login:
<form id ="loginForm" name="loginForm" action="login.php" method="post">
Username: <input type="text" name="username" />
<br/>
Password: <input type="password" name="password" />
<input type="submit" value="Login" />
</form>
</div>
<div id="WeatherWidget">
<script type="text/javascript" src="externalDomain.example.com/weatherwidget.js"></script>
</div>
</div>
This webpage is now only as secure as the external domain it is including functionality from. If an
attacker compromised the external domain and could add malicious scripts to the weatherwidget.js
file, the attacker would have complete control, as seen in any XSS weakness (CWE-79).
For example, user login information could easily be stolen with a single line added to
weatherwidget.js:
Example Language: JavaScript (Attack)
...Weather widget code....
CWE Version 4.14
CWE-829: Inclusion of Functionality from Untrusted Control Sphere
CWE-829: Inclusion of Functionality from Untrusted Control Sphere