[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] [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@xxxxxxxxxxxxxxx> 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/