the-web-application-hackers-handbook

494 Chapter 12 n Attacking Users: Cross-Site Scripting
if user data is inserted into a quoted JavaScript string in an event handler, any
quotation marks or backslashes in user input should be properly escaped with
backslashes, and the HTML encoding should include the & and ; characters to
prevent an attacker from performing his own HTML encoding.
ASP.NET applications can use the Server.HTMLEncode API to sanitize common
malicious characters within a user-controllable string before this is copied
into the server’s response. This API converts the characters “&< and > into their
corresponding HTML entities and also converts any ASCII character above 0x7f
using the numeric form of encoding.
The Java platform has no equivalent built-in API; however, it is easy to construct
your own equivalent method using just the numeric form of encoding.
For example:
public static String HTMLEncode(String s)
{
StringBuffer out = new StringBuffer();
for (int i = 0; i < s.length(); i++)
{
char c = s.charAt(i);
if(c > 0x7f || c==’”’ || c==’&’ || c==’’)
out.append(“&#” + (int) c + “;”);
else out.append(c);
}
return out.toString();
}
A common mistake developers make is to HTML-encode only the characters
that immediately appear to be of use to an attacker in the specific context. For
example, if an item is being inserted into a double-quoted string, the application
might encode only the “ character. If the item is being inserted unquoted
into a tag, it might encode only the > character. This approach considerably
increases the risk of bypasses being found. As you have seen, an attacker can
often exploit browsers’ tolerance of invalid HTML and JavaScript to change
context or inject code in unexpected ways. Furthermore, it is often possible to
span an attack across multiple controllable fields, exploiting the different filtering
being employed in each one. A far more robust approach is to always HTMLencode
every character that may be of potential use to an attacker, regardless
of the context where it is being inserted. To provide the highest possible level
of assurance, developers may elect to HTML-encode every nonalphanumeric
character, including whitespace. This approach normally imposes no measurable
overhead on the application and presents a severe obstacle to any kind of
filter bypass attack.
The reason for combining input validation and output sanitization is that this
involves two layers of defenses, either one of which provides some protection
if the other one fails. As you have seen, many filters that perform input and