the-web-application-hackers-handbook

536 Chapter 13 n Attacking Users: Other Techniques
Preventing Header Injection Vulnerabilities
The most effective way to prevent HTTP header injection vulnerabilities is to
not insert user-controllable input into the HTTP headers that the application
returns. As you saw with arbitrary redirection vulnerabilities, safer alternatives
to this behavior usually are available.
If it is considered unavoidable to insert user-controllable data into HTTP
headers, the application should employ a twofold defense-in-depth approach
to prevent any vulnerabilities from arising:
n Input validation—The application should perform context-dependent
validation of the data being inserted in as strict a manner as possible.
For example, if a cookie value is being set based on user input, it may be
appropriate to restrict this to alphabetical characters only and a maximum
length of 6 bytes.
n Output validation—Every piece of data being inserted into headers should
be filtered to detect potentially malicious characters. In practice, any character
with an ASCII code below 0x20 should be regarded as suspicious,
and the request should be rejected.
Applications can prevent any remaining header injection vulnerabilities from
being used to poison proxy server caches by using HTTPS for all application
content, provided that the application does not employ a caching reverse-proxy
server behind its SSL terminator.
Cookie Injection
In cookie injection attacks, the attacker leverages some feature of an application’s
functionality, or browser behavior, to set or modify a cookie within the
browser of a victim user.
An attacker may be able to deliver a cookie injection attack in various ways:
n Some applications contain functionality that takes a name and value in
request parameters and sets these within a cookie in the response. A
common example where this occurs is in functions for persisting user
preferences.
n As already described, if an HTTP header injection vulnerability exists,
this can be exploited to inject arbitrary Set-Cookie headers.
n XSS vulnerabilities in related domains can be leveraged to set a cookie on
a targeted domain. Any subdomains of the targeted domain itself, and
of its parent domains and their subdomains, can all be used in this way.
n An active man-in-the-middle attack (for example, against users on a public
wireless network) can be used to set cookies for arbitrary domains, even