Can you help me better understand the risk to an end user this represents? I just recently implemented some similar login redirect logic and want to make sure I'm handling the redirect value properly.

It's a somewhat complicated variant of reflected cross-site scripting, a.k.a. Javascript injection.†

The vulnerability in response-splitting is passing attacker-controlled newlines unmolested through HTTP header content. Newlines terminate headers. Attacker-controlled content in a redirect that is allowed to contain newlines enables attackers to inject new headers or to terminate the header portion of the request.

Here, Neal's using the attack to inject a false end-of-headers newline and then a fake request body containing Javascript.

The attack is trivial to prevent; just don't allow newlines (and, ideally, active HTML characters) in redirect content.

† The goal of an attacker is to coerce a server into sending her own Javascript; the same-origin rules governing browser security allow that Javascript access to the server's cookies, even though the code is under the control of an attacker.

> "The attack is trivial to prevent; just don't allow newlines (and, ideally, active HTML characters) in redirect content."

Surely the more correct solution is to escape them properly.

eg in the example:

  Location: javascript:
 
  <script>alert(document.cookie)</script>

occurs because something unescaped the %0D%0A%0D%0A. If however you just leave it as it was originally, or alternatively encode it properly after you've decoded it.

  Location: javascript:%0D%0A%0D%0A<script>alert(document.cookie)</script>

and everything works as it should.

You're right; I wasn't prescriptive enough. Thanks for clarifying.

Wasn't Cache poisoning possible as well?

Yes. I chose to demonstrate it using an XSS vulnerability because it makes for a much easier to understand PoC (you click on a link and see an alert box). ;)

Had the XSS vulnerabilities failed, I would have spent more time investigating the cache poisoning possibilities.