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

Chapter 12 

■

Attacking Other Users

423

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

---

Having identified all of the operations which are potentially at risk of XSS

and which need to be suitably defended, a threefold approach should be taken

to prevent any actual vulnerabilities arising. This approach comprises the fol-

lowing elements:

■■

Validate input.

■■

Validate output.

■■

Eliminate dangerous insertion points.

Validate Input

At the point where the application receives user-supplied data that may be

copied into one of its responses at any future point, the application should per-

form context-dependent validation of this data, in as strict a manner as possi-

ble. Potential features to validate include the following:

■■

That the data is not too long.

■■

That the data only contains a certain permitted set of characters.

■■

That the data matches a particular regular expression.

Different validation rules should be applied as restrictively as possible to

names, email addresses, account numbers, and so on, according to the type of

data that the application is expecting to receive in each field.

Validate Output

At the point where the application copies into its responses any item of data

that originated from some user or third party, this data should be HTML-

encoded to sanitize potentially malicious characters. HTML-encoding

involves replacing literal characters with their corresponding HTML entities.

This ensures that browsers will handle potentially malicious characters in a

safe way, treating them as part of the content of the HTML document and not

part of its structure. The HTML-encodings of the primary problematic charac-

ters are as follows:

“    "

‘    '

&    &

<    <

>    >

In addition to these common encodings, in fact any character can be HTML-

encoded using its numeric ASCII character code, as follows:

%    %

*    *