The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

Chapter 12 

■

Attacking Other Users

425

70779c12.qxd:WileyRed  9/14/07  3:14 PM  Page 425

---

Of course, when devising the input and output validation logic itself, great

care should be taken to avoid any vulnerabilities that lead to bypasses. In par-

ticular, filtering and encoding should be carried out after any relevant canoni-

calization, and the data should not be further canonicalized afterwards. The

application should also ensure that the presence of any null bytes does not

interfere with its validation.

Eliminate Dangerous Insertion Points

There are some locations within the application page where it is just too inher-

ently dangerous to insert user-supplied input, and developers should look for

an alternative means of implementing the desired functionality.

Inserting user-controllable data directly into existing JavaScript should be

avoided wherever possible. When applications attempt to do this safely, it is

frequently possible to bypass their defensive filters. And once an attacker has

taken control of the context of the data he controls, he typically needs to per-

form minimal work to inject arbitrary script commands and so perform mali-

cious actions.

A second location where user input should not be inserted is any other con-

text in which JavaScript commands may appear directly. For example:

In these situations, an attacker can proceed directly to injecting JavaScript

commands within the quoted string. Further, the defense of HTML-encoding

the user data may not be effective, because some browsers will HTML-decode

the contents of the quoted string before this is processed. For example:

A further pitfall to avoid is situations where an attacker can manipulate the

encoding type of the application’s response, either by injecting into a relevant

directive or because the application uses a request parameter to specify the

preferred encoding type. In this situation, input and output filters that are well

designed in other respects may fail because the attacker’s input is encoded in

an unusual form that the filters do not recognize as potentially malicious.

Wherever possible, the application should explicitly specify an encoding type

in its response headers, disallow any means of modifying this, and ensure that

its XSS filters are compatible with it. For example:

Content-Type: text/html; charset=ISO-8859-1