I'll make it "won't fix".
--
Yasuo Ohgaki
Melvyn Sopacua wrote:
> On Sun, 8 Sep 2002, Yasuo Ohgaki wrote:
>
> YO>>> Date: Sun, 08 Sep 2002 11:01:44 +0900
> YO>>> From: Yasuo Ohgaki <[EMAIL PROTECTED]>
> YO>>> To: [EMAIL PROTECTED]
> YO>>> Subject: [PHP-DEV] Re: #19286 [NEW]: header() Control Char Injection
> YO>>>
> YO>>> Yasuo Ohgaki wrote:
> YO>>> > This obvious security risk is mentioned in bugtraq today.
>
> Since when is PHP responsible for unvalidated user input? I think the
> documentation already states:
> " Variables provided to the script via any user input mechanism, and which
> therefore cannot be trusted. "
>
> The superglobals are exactly for this reason - that the user knows, this
> input should be validated.
>
> YO>>> >
> YO>>> > IMHO, this is users' fault. They must check values before
> YO>>> > using it. In this specfic case, user should use simple regex
> YO>>> > before feeding str to header().
> YO>>> >
> YO>>> > Any opinion to meke this to "won't fix"?
> YO>>>
> YO>>> One thing we could do is force header parameter a single line.
> YO>>> Any idea it may broke applications?
>
> header("Content-Type: text/plain;\n\tfilename=\"filename.txt\"");
>
> RFC 2616:
> HTTP/1.1 header field values can be folded onto multiple lines if the
> continuation line begins with a space or horizontal tab. All linear
> white space, including folding, has the same semantics as SP. A
> recipient MAY replace any linear white space with a single SP before
> interpreting the field value or forwarding the message downstream.
>
> LWS = [CRLF] 1*( SP | HT )
>
> So, the error in this case, would be that \r\n\r\n is accepted as a
> valid header, but since the line isn't continued with a space or tab,
> the header is not valid.
>
> Isn't that the webserver's or even the client's responsibility to
> accept that header? I.e.: Does it redirect? And if not - it's end of
> content and this writes a body.
>
> It's the same user-responsibility as hosting a forum:
> the forum-software is responsible for proper HTML escaping, not the
> language it's written in.
>
> YO>>>
> YO>>> --
> YO>>> Yasuo Ohgaki
> YO>>>
> YO>>> >
> YO>>> > --
> YO>>> > Yasuo Ohgaki
> YO>>> >
> YO>>> > [EMAIL PROTECTED] wrote:
> YO>>> >
> YO>>> >> From: [EMAIL PROTECTED]
> YO>>> >> Operating system: Win32
> YO>>> >> PHP version: 4.2.3
> YO>>> >> PHP Bug Type: Output Control
> YO>>> >> Bug description: header() Control Char Injection
> YO>>> >>
> YO>>> >> I made a quite primitive use of the header() function in a redirect
> YO>>> >> script:
> YO>>> >>
> YO>>> >> <?php
> YO>>> >> if (isset($_GET["url"])) {
> YO>>> >> header("Location: " . $_GET["url"]);
> YO>>> >> }
> YO>>> >> ?>
> YO>>> >>
> YO>>> >> But, no imagine for a second:
> YO>>> >>
> YO>>> >>
>url=http%3A%2F%2Fwww.yahoo.com%2F%0D%0A%0D%0A%3Cscript%3Ealert%28document.cookie%29%3B%3C%2FSCRIPT%3E%0D%0A%0D%0A
>
> YO>>> >>
> YO>>> >>
> YO>>> >> Which causes:
> YO>>> >>
> YO>>> >> Location: http://www.yahoo.com/
> YO>>> >>
> YO>>> >> <script>alert(document.cookie)</script>
> YO>>> >>
> YO>>> >> Another interesting thing about this is that it (possibly) allows
> YO>>> >> bypassing output buffering(?).
> YO>>> >>
> YO>>> >> If nothing else, this is a documentation problem, as the header() docs
> YO>>> >> say
> YO>>> >> that it will modify a single header, but it also allows body content
> YO>>> >> to be
> YO>>> >> manipulated.
> YO>>> >
> YO>>> >
> YO>>>
> YO>>>
> YO>>>
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
