Subject: clients ignoring brokenness of sites

From: Adrien de Croy <[email-masked]>
Date: Thu, 23 Jul 2009 14:00:25 +1200

Hi all

sorry, normally I wouldn't bother the list about this, but we had 
reports from a customer about a site that caused our proxy to return an 
error about a server malformed response.

The server response looked like this:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 22 Jul 2009 02:33:56 GMT
X-Powered-By: ASP.NET
Connection: close
PHP Warning:  PHP Startup: sdo: Unable to initialize module
Module compiled with module API=20060613, debug=0, thread-safety=1
PHP    compiled with module API=20050922, debug=0, thread-safety=1
These options need to match
in Unknown on line 0
X-Powered-By: PHP/5.1.5
Content-type: text/html; charset=iso-8859-1

Normally this wouldn't be particularly interesting - just another broken 
site.  However all the browsers I tested swallowed this without 
complaining and displayed the body.  I tested IE8, Chrome, FF3.5 and 
Opera 9.6.4.  Each of the lines in the response was terminated by CRLF 
(not bare LF), so I'm struggling to see how anyone can interpret the PHP 
warning as anything resembling a valid header (even wrapped, since no 
leading WS).

Isn't this a potentially serious security problem?

It's hard to be the only proxy that decides to demonstrate how broken 
this site is - customers don't understand....

Cheers

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Adrian Chadd <[email-masked]>
Date: Thu, 23 Jul 2009 10:16:16 +0800

> These options need to match

Hah nice!

> this site is - customers don't understand....

I've been seeing other random non-header stuff in HTTP reply headers.
Squid also complains and iirc drop the request as invalid by default.

HTTP/1.1 200 OK                                                                                                                                                    
Content-Type: image/jpeg                                                                                                                                           
Vary: Accept-Encoding                                                                                                                                              
Accept_170C_49EDDAC0                                                                                                                                               
expires: Thu, 15 Apr 2011 20:00:00 GMT                                                                                                                             
Content-Length: 5900                                                                                                                                               
Date: Mon, 13 Jul 2009 08:17:12 GMT                                                                                                                                
Connection: close                                                                                                                                                  
age: 0                                                                                                                                                             
X-Cache: HIT

I'd love to know what generates that.

Adrian

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 23 Jul 2009 15:43:46 +1200

my issue is that there will never be any incentive for sites to clean
themselves up as long as browsers ignore the problems (This particular
problem is not helped either by IIS5 not enforcing compliance of script
output).

This then puts pressure on proxy vendors to follow the lead of the
browsers, and basically ignore / work around the problems, or attempt
to clean up the response.

This is the spawning ground of security problems.

I can see why a browser would do this - you don't want to be the only
browser on the block to not work with a site.  But it's bad for the web.

Even if the browser showed the page but popped a warning dialog would
be miles better, that would then provide some incentive to the site
operators to fix such problems.

Maybe a recommendation for the RFC?  It's probably already in there,
although I looked through p1-messaging-07, esp S 4.2, and Appendix A,
and I couldn't see any requirements for what a receiver of broken
headers must do.

Regards

Adrien

Adrian Chadd wrote:

Hah nice!

HTTP/1.1 200 OK
Content-Type: image/jpeg
Vary: Accept-Encoding
Accept_170C_49EDDAC0

Adrian

---

From: Adam Barth <[email-masked]>
Date: Wed, 22 Jul 2009 21:06:16 -0700

On Wed, Jul 22, 2009 at 8:43 PM, Adrien de Croy<[email-masked]> wrote:
> This then puts pressure on proxy vendors to follow the lead of the browsers,
> and basically ignore / work around the problems, or attempt to clean up the
> response.
>

Indeed.

In the alternative, one could produce an HTTP spec that contained
detailed error recovery instructions.  This approach would save the
next proxy vendor from having to relearn these lessons the hard way.

Adam

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 23 Jul 2009 21:48:12 +0200

> warning as anything resembling a valid header (even wrapped, since no 

Heh..

your message got me to test how Squid behaves, and the result was not
quite what I remembered. It by default logs those non-header error lines
without a : in the debug log and strips them from the response. In this
setting it also removes spaces before : if any is seen. There is a
setting to barf loudly and reject the response but it's not enabled by
default (it then stops at "PHP Warning:" barfing on the space
character).

Servers allowing applications to send headers like this is a security
issue as they open up for cache poisoning attacks if an attacker can
inject data there, but provided proxies handle corrupted messages
reasonably well it's isolated to their own content so it's not
considered a major issue.

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 25 Jul 2009 01:00:10 +0100

> I'd love to know what generates that.

It's nice to have dirty examples.

Wait for it.  I've seen this:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345
CP="FOO BAR WIBBLE STUFF": CP="FOO BAR WIBBLE STUFF"

The CP= string is the right hand side of a P3P header, but I've seen
it duplicated as the header name and value, complete with quote
characters and spaces in some responses from sites running IIS.  It
was about 5 years ago; I'm reconstructing this from memory.  I don't
remember which site, but it wasn't an obscure one.

-- Jamie