Re: Re: #19286 [NEW]: header() Control Char Injection

From: Date: Sun, 08 Sep 2002 02:38:34 +0000
Subject: Re: Re: #19286 [NEW]: header() Control Char Injection
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-88056@lists.php.net to get a copy of this message
On Sun, 8 Sep 2002, Yasuo Ohgaki wrote: YO>>> Date: Sun, 08 Sep 2002 11:01:44 +0900 YO>>> From: Yasuo Ohgaki <yohgaki@ohgaki.net> YO>>> To: php-dev@lists.php.net 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>>> > mattmurphy@kc.rr.com wrote: YO>>> > YO>>> >> From: mattmurphy@kc.rr.com 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>>> >> 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>>> >> 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>>> -- Melvyn.

« previous php.dev (#88056) next »