Date: Wed, 25 Apr 2007 15:49:47 +0200
From: Vincent Archer <varcher@...yall.com>
To: admin@...ibase.ca
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache/PHP REQUEST_METHOD XSS Vulnerability

On Wed, 2007-04-25 at 07:48 -0400, Kradorex Xeron wrote:
> If you properly code the scripts, Apache's acceptance of misc data in the 
> method field is not a vulnerability, it is a feature that could be used to 
> make that field extensible with minimal effort. i.e. a script could be 
> designed to send out data based on different methods not listed in the RFC.

And that's probably why it's doing so. However, after calling
ap_getword_white to fetch the method from the first line, apache does
nothing as a validation step. It checks if it's among known strings (to
set the methode_number value), but that's all. Which I find
lacking/lazy.

> True. but Apache should not facilitate lazy programming on script programmers 
> part, the more you baby sit people, the more they will rely on that 
> babysitting and not do it for themselves because they will inherently assume 
> that they have a 'safety net', thus if the script is run on a server without 
> that "safety net" THAT server gets labeled as "vunlnerable" when without that 
> script the server is not vulnerable.

I'm a strong proponent of well defined "responsabilities" in software
components. I'm also a strong proponent of having basic capabilities
placed in the basic libraries/software framework, rather than forcing
every single programmer to re-develop the exact same validation steps on
each project.

What you call babysitting, I call allocating programming ressources to
the greatest good... and like most of the thing in software engineering,
it's a matter of compromise: too much in the basic framework and you
lose flexibility, too much in the "userland" and you have to reinvent
the wheel each time.

> What are we going to do next? get the HTTPD to valadate the URL-based queries 
> (i.e. "script.php?var=value") to prevent "unintended input" 
> (i.e. "viewfile.php?file=../../../file" )? This is a SCRIPT problem. not a 
> problem with the HTTPD. 

Non, because there's no well-defined rules in HTTP about the var=value.
However, if you're using a framework that parses the url, and you
defined "file" as being a "local file", then you might expect your
framework to reject somehow out of the box the directory traversal.

> From RFC 2616 Section 5.1.1:
> The list of methods allowed by a resource can be specified in an Allow header 
> field (section 14.7). The return code of the response always notifies the 
> client whether a method is currently allowed on a resource, since the set of 
> allowed methods can change dynamically. 
> --------
> 
> The standards don't say anything about a static list of methods being 
> required. so Apache is compliant there. It is a per-script problem for not 
> parsing the raw data provided to the script properly.

No, but as the RFC says (and already repeated in this thread), the legal
methods are well defined as being of type "token". And tokens can't
include characters like <, (, or ". And that's where apache fails: it
lets you use additional methods, sure, but it also doesn't validate
anything - even though it could.

The debate here is: whose responsability is it to validate well-defined
input? The framework, or each application developper? IMHO, it shouldn't
be unreasonable to expect apache to enforce the standards, nothing more,
but nothing less.

-- 
Vincent ARCHER
varcher@...yall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 23, rue Notre Dame des Victoires - 75002 Paris - France

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists