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] [day] [month] [year] [list]
Date: Tue, 24 Apr 2007 11:44:14 +0200
From: "Michal Majchrowicz" <m.majchrowicz@...il.com>
To: "Richard Moore" <rich@...tpoint.ltd.uk>, full-disclosure@...ts.grok.org.uk
Subject: Re: Apache Illegal Request Handling Possible XSS
	Vulnerability

In this case I agree this is a solution. If Apache wouldn't accept any
'separators' then XSS (and other stuff) wouldn't be possible at all.
Is there anywhere described which chars can be used in protocol
"field"?
Regards Michal.

On 4/24/07, Richard Moore <rich@...tpoint.ltd.uk> wrote:
> 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ