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>] [day] [month] [year] [list]
Message-ID: <3d3168e50704240351p21b560dep350ec185690003ba@mail.gmail.com>
Date: Tue, 24 Apr 2007 12:51:18 +0200
From: "Michal Majchrowicz" <m.majchrowicz@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: [VulnWatch] Apache/PHP REQUEST_METHOD XSS
	Vulnerability

Hi.
I am talking about standard apache installation. And there is
something like this only:
 <Directory /home/*/public_html>
       AllowOverride FileInfo AuthConfig Limit -Indexes
       Options MultiViews -Indexes SymLinksIfOwnerMatch IncludesNoExec
       <Limit GET POST OPTIONS PROPFIND>
           Order allow,deny
           Allow from all
      </Limit>
      <LimitExcept GET POST OPTIONS PROPFIND>
           Order deny,allow
           Deny from all
      </LimitExcept>
   </Directory>
Regards Michal.

On 4/24/07, Bennett, Steve <s.bennett@...caster.ac.uk> wrote:
>
> > There exist a flaw in a way how Apache and php combination handle the
> > $_SERVER array.
> > If the programmer writes scrip like this:
> > <?php
> >               echo $_SERVER['REQUEST_METHOD'];
> > ?>
> > He will assume that REQUEST_METHOD can only by: GET,POST,OPTIONS,TRACE
> > and all that stuff. However this is not true, since Apache accepts
> > requests that look like this:
> > GET<script>alert(document.coookie);</script> /test.php HTTP/1.0
> > And the output for this would be:
> > GET<script>alert(document.coookie);</script>
> > Of course it is hard to exploit (I think some Flash might help ;)) and
> > I don't know if it is exploitable at all. But programmers should be
> > warned about this behaviour. You can't trust any  variable in the
> > $_SERVER table!
>
> Hi Michal,
>
> I think you're mistaken in this. Perhaps you have a broken apache config
> file?
>
> It's standard to have something like the following in access control
> sections:
>     <Limit GET POST OPTIONS PROPFIND>
>         Order allow,deny
>         Allow from all
>     </Limit>
>     <LimitExcept GET POST OPTIONS PROPFIND>
>         Order deny,allow
>         Deny from all
>     </LimitExcept>
>
> This limits request methods to be (in this case) one of "GET", "POST",
> "OPTIONS" and "PROPFIND". Any other values result in a 403 error (and
> yes I've tested this).
>
> I agree with the sentiment that applications should be paranoid about
> any external input, but I don't see any way that the method you describe
> can be exploited except on a deliberately misconfigured system.
>
> Steve.
>

_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ