full-disclosure - Re: Apache/PHP REQUEST

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200704250748.27674.admin@digibase.ca>
Date: Wed, 25 Apr 2007 07:48:26 -0400
From: Kradorex Xeron <admin@...ibase.ca>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache/PHP REQUEST_METHOD XSS Vulnerability

On Wednesday 25 April 2007 05:35, Vincent Archer wrote:
> On Tue, 2007-04-24 at 20:03 +0300, عبد الله احمد عنان wrote:
> > This is a case of poor-programming, on the script coder's part, it is
> > not so
> > much a vunerability.
>
> In that case, nobody's talking about vulnerabilities on this list, only
> poor programming. :)

Vulnerabilities are results of poor programming.

>
> The problem in here is that the programmer "assumes" that the variables
> do have a proper value checking done prior to handling off to the script
> engine. HTTP_METHOD is well defined. One would assume apache has
> validated the method somehow.
>

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.

> Unfortunately, this assumption was flawed.
>
> > That variable only contains what it is sent by apache. it doesn't
> > parse it.
> > nor is it supposed to.
>
> However, it (apache) should perform integrity checks, because it has the
> capacity to do so.
>

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.

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. 

> > This CAN be a vulnerability with individual scripts, however, it is
> > not a vuln
> > with PHP or Apache.
>
> Not with PHP. But I would agree with the original programmer that apache
> is in fault here. Apache should have done the expected work, and
> validated that the request was standards-compliant. It didn't, and that
> opens up a huge chasm in which plenty of problems, vulnerabilities and
> others, may hide.

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.

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