full-disclosure - Re: Apache Illegal Request Handling Possible XSS Vulnerability

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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <462DCF45.8060904@westpoint.ltd.uk>
Date: Tue, 24 Apr 2007 10:35:01 +0100
From: Richard Moore <rich@...tpoint.ltd.uk>
To: Michal Majchrowicz <m.majchrowicz@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache Illegal Request Handling Possible XSS
 Vulnerability

Michal Majchrowicz wrote:
> Okay so let's assume that there cany "anything" as the request. But
> there has to be something that handles this request? If there is no
> "handler" for request "<script>" Apache should return error page. And
> what about protocol version? You didn't answer this question.
> Regards Michal.

The handler here is your script - there's no way for apache to
know what your script does. It is the responsibility of the script
to raise an error in this case.

To be precise the HTTP specification (RFC 2616) says a method is:

     Method         = "OPTIONS"                ; Section 9.2
                       | "GET"                    ; Section 9.3
                       | "HEAD"                   ; Section 9.4
                       | "POST"                   ; Section 9.5
                       | "PUT"                    ; Section 9.6
                       | "DELETE"                 ; Section 9.7
                       | "TRACE"                  ; Section 9.8
                       | "CONNECT"                ; Section 9.9
                       | extension-method
     extension-method = token

Now, token is defined by these productions:

  token          = 1*<any CHAR except CTLs or separators>

  CHAR           = <any US-ASCII character (octets 0 - 127)>

  separators     = "(" | ")" | "<" | ">" | "@"
                       | "," | ";" | ":" | "\" | <">
                       | "/" | "[" | "]" | "?" | "="
                       | "{" | "}" | SP | HT

  CTL            = <any US-ASCII control character
                         (octets 0 - 31) and DEL (127)>

So that implies that Apache is being slightly lax in passing arbitrary
content. However, there is no fixed list of valid methods as you can
define your own as an extension-method. This is used by a number of
protocols. Apache should probably raise an error if the method
contains characters outside these defined productions.

Cheers

Rich.


> 
> On 4/24/07, Richard Moore <rich@...tpoint.ltd.uk> wrote:
>> Michal Majchrowicz wrote:
>> > Hi.
>> > I think that server should have a list of valid requests. In fact
>> > Apache warns you sometimes that valid requests are:
>> > "GET/POST/TRACE/OPTIONS". The solution that it just accepts everything
>> > as request and protocol makes no sense. What kind of protocol is
>>
>> It makes lots of sense as I said - protocols like WebDAV are
>> layered on top of HTTP and are implemented in apache using the
>> exact same API as PHP uses. They need to add methods like PROPFIND
>> etc. Unless they are required to define the exact set of verbs
>> supported by every page then there's no way to define a fixed
>> list.
>>
>> I do however agree that it could be restricted to something like
>> [A-Z0-9]+ as I said.
>>
>> Cheers
>>
>> Rich.
>>
>> > "<script>"?
>> > Regards Michal.
>> >
>> > On 4/24/07, Richard Moore <rich@...tpoint.ltd.uk> wrote:
>> >> Michal Majchrowicz wrote:
>> >> > Hi.
>> >> > I think now we can classify this as flaw in Apache. It accepts
>> >> > requests that simply make no sense. Take a look at this example:
>> >> > <script>alert(document.cookie);</script> /test.php
>> >> > <script>alert(document.cookie);</script>
>> >> > In some circumstances it may cause XSS vulnerability:
>> >> > <?php
>> >> >         echo $_SERVER['REQUEST_METHOD'];
>> >> >         echo $_SERVER['SERVER_PROTOCOL'];
>> >> > ?>
>> >>
>> >> As Kradorex Xeron said, that's a flaw in the script. Apache needs
>> >> to let arbitrary verbs through to the PHP (or other server extension)
>> >> otherwise tools like webdav that require additional verbs could not
>> >> be implemented. It is possibly arguable that it should restrict the
>> >> verbs to a single alphanumeric string, but it certainly can't be
>> >> counted on to be just GET/POST etc.
>> >>
>> >> Cheers
>> >>
>> >> Rich.
>> >>
>> >> > I am now investigating other possible attacks.
>> >> > Regards Michal Majchrowicz.
>> >> >
>> >> > _______________________________________________
>> >> > Full-Disclosure - We believe in it.
>> >> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> >> > Hosted and sponsored by Secunia - http://secunia.com/
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Richard Moore, Principal Software Engineer,
>> >> Westpoint Ltd,
>> >> Albion Wharf, 19 Albion Street, Manchester, M1 5LN, England
>> >> Tel: +44 161 237 1028
>> >> Fax: +44 161 237 1031
>> >>
>> >
>> >
>>
>>
>> -- 
>> Richard Moore, Principal Software Engineer,
>> Westpoint Ltd,
>> Albion Wharf, 19 Albion Street, Manchester, M1 5LN, England
>> Tel: +44 161 237 1028
>> Fax: +44 161 237 1031
>>
> 
> 


-- 
Richard Moore, Principal Software Engineer,
Westpoint Ltd,
Albion Wharf, 19 Albion Street, Manchester, M1 5LN, England
Tel: +44 161 237 1028
Fax: +44 161 237 1031

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