How to escape the Location: header value properly?

In my webapp I'm using HTTP Location: headers for redirect (e.g. POST/redirect/GET). But the target locations have to be dynamic (e.g. login.php?dest=pagexy.php). We all know that any user-modifiable input has to be properly escaped to prevent XSS, so

 header('Location: '.$_REQUEST['dest']);

looks wrong. Simple urlencode-ing can only be used for simple files, not paths (e.g. cross-domain URLs with Single-Sign-On).

I've also read about vulnerabilities like:

Locati开发者_Python百科on: javascript:...bad.stuff...  or
Location: data:text/html:base64,...

Having an explicit whitelist of destinations would probably the most secure solution, but is tedious and might even not be possible for all use-cases.

Solutions?

Edit:

1. Is urlencoding enough/correct for simple files? Assume a recent PHP version (> 5.1.2, AFAIK) that forbids newlines in header().

2. How can I safely handle cross-domain credential-checking without knowing each other-domain beforehand?

---

Simple: DON'T EVER DO THAT.

If you must redirect the user, don't ever let them tell you where they are going.

If you absolutely must do that, urlencode the the input, whitelist the domains, and strip parameters that you haven't whitelisted. Better yet, don't let them tell you what domain - produce that using some other backend switch.

If you don't seriously lock that down, you will be vulnerable to all kinds of things. Be especially careful that they can't put a linebreak in there.

More info:

• http://www.owasp.org/index.php/Testing_for_HTTP_Splitting/Smuggling_(OWASP-DV-016)
• http://www.owasp.org/index.php/XSS

---

There actually occurs three kinds of attacks:

1. HTTP Response Splitting, but as mentioned is some the comments, header() filters CRLF symbols.
2. Open Redirect, which I suppose cannot be mitigated in your case.
3. XSS. urlencode() is useless, don't bother it. You should make sure URL is http:// (or https://) as long as it's possible to make redirect to javascript: (some browsers allow it, but not all) and data: URIs.

For more information on Open Redirect and its issues see presentation at OWASP AppSec 2010 by sirdarckcat and thornmaker