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

Chapter 12 

■

Attacking Other Users

433

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

---

As with DOM-based XSS vulnerabilities, it is recommended that applica-

tions do not perform redirects via client-side scripts on the basis of DOM data,

as this data is outside of the server’s direct control. 

HTTP Header Injection

HTTP header injection vulnerabilities arise when user-controllable data is

inserted in an unsafe manner into an HTTP header returned by the applica-

tion. If an attacker can inject newline characters into the header he controls, he

can insert additional HTTP headers into the response and can write arbitrary

content into the body of the response.

This vulnerability arises most commonly in relation to the 

Location

and

Set-Cookie

headers, but it may conceivably occur for any HTTP header. You

saw previously how an application may take user-supplied input and insert

this into the 

Location

header of a 3xx response. In a similar way, some appli-

cations take user-supplied input and insert this into the value of a cookie. For

example:

GET /home.php?uid=123 HTTP/1.1

Host: wahh-app.com

HTTP/1.1 200 OK

Set-Cookie: UserId=123

...

In either of these cases, it may be possible for an attacker to construct a

crafted request using the carriage-return (

0x0d

) and/or line-feed (

0x0a

) char-

acters to inject a newline into the header they control, and so insert further

data on the following line. For example:

GET /home.php?uid=123%0d%0aFoo:+bar HTTP/1.1

Host: myapp.com

HTTP/1.1 200 OK

Set-Cookie: UserId=123

Foo: bar

...