httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [RFC] CGIPassHeader Authorization|Proxy-Authorization|...
Date Tue, 19 Aug 2014 12:59:20 GMT
On Mon, Aug 18, 2014 at 7:09 PM, Graham Dumpleton <grahamd@apache.org>
wrote:

> The problem is sys admins who don't know what they are doing as far as
> administering Apache.
>
> I used to work in a corporate environment where they allowed everyone a
> ~username directory for placing stuff. As they wanted to allow people to
> setup certain type of scripts in their directory, they allowed .htaccess
> files.
>
> Only thing wrong with that is that they also required you to authenticate
> using HTTP basic authentication with your own credentials to access anyones
> ~username directory.
>
> Using any of the backdoors you could harvest credentials by getting others
> in the company to go to your personal ~username area.
>
> So in some respects if a directive is going to be provided, it has to be
> something that can be consulted by any module and all core modules which
> have such backdoor ways of getting at the authorisation header should be
> changed to block access if the directive hasn't been set to allow access to
> that header.
>

Hmmm...  In order for the various htaccess tricks to be blockable, I think
that any module that references a "protected" HTTP header based on rules in
.htaccess or other user-editable files (i.e., constructs of the module
itself) in a manner that could conceivably pass it to untrusted code would
have to use an API to verify each access.  (Handling authn based on
htaccess rules would not need to be verified; setting an envvar based on an
HTTP header would need to be verified.)  In some cases it wouldn't be so
clear.  In general purpose code that could conceivably be used to expose
such data, such as 2.4's expression support, new variations would be needed
that allow the caller to indicate when HTTP header accesses should be
verified.

Perhaps I'm making this too complicated ;)  Given the general purpose
access to headers within some httpd features, it doesn't seem like a simple
problem.

--/--

Even though CGIPassHeader itself in htaccess doesn't expose information
that couldn't be obtained by less obvious means, there is at least some
value in controlling whether or not it can be used in htaccess; having a
speed bump on this "natural" solution is a way get some people to read
warnings about the combination of authn-by-httpd and authn-by-application.
 (Speed bump or no speed bump, AuthType -- telling httpd to perform authn
in a particular manner -- documentation should mesh with CGIPassHeader
documentation on the issue.)

I'm +0.75 or so for having to explicitly enable the use of CGIPassHeader in
htaccess.


>
> If this was possible then I would certainly change mod_wsgi to be gated by
> the directive as an extra step as I can't say that I am happy that I
> allowed myself to be pushed into allowing enabling in .htaccess files with
> the mod_wsgi option.
>

Sure; even without addressing the entire problem completely, any module
could consult the CGIPassHeader setting (and decide what to do for
migration purposes if it is unset).


>
> Graham
>
>
>
> On 19 August 2014 06:29, André Malo <nd@perlig.de> wrote:
>
>> Hi,
>>
>> only short notes from me. I'd appreciate such a directive very much. I
>> think, allowing it in .htaccess won't hurt. I can't come up with a use
>> case, where the person behind the script doesn't have access to the
>> credentials anyway.
>>
>> As for the passing right now, you don't need the whole mod_rewrite
>> machinery
>> for this:
>>
>> SetEnvIf Authorization (.+) HTTP_AUTHORIZATION=$1
>>
>> that's, what I've been using so far :)
>>
>> nd
>>
>> * Graham Dumpleton wrote:
>>
>> > A few comments on this.
>> >
>> > The first is that mod_wsgi originally never allowed its
>> > WSGIPassAuthorization directive in a htaccess file, and then when it it
>> > did first allow it, it was only honoured if AuthConfig was allowed for
>> > that context.
>> >
>> > I kept having people who needed that ability when they had a htaccess
>> > file, but didn't have AuthConfig.
>> >
>> > One of the things that was pointed out was that if you have htaccess
>> > enabled, and mod_rewrite was being loaded into Apache, you could get
>> > access to the Authorization header anyway.
>> >
>> >     RewriteEngine on
>> >     RewriteBase /
>> >     RewriteCond %{HTTP:Authorization}  ^(.*)
>> >     RewriteRule ^(.*)$ $1 [e=HTTP_AUTHORIZATION:%1]
>> >
>> > In the end, since mod_wsgi arguably shouldn't ever be used in shared
>> > environments anyway, I ended up caving in and allowing
>> > WSGIPathAuthorization in htaccess to make it convenient for the more
>> > typical scenario that kept coming up.
>> >
>> > Now having the ability within mod_wsgi for a web application to handle
>> > authorisation this showed up a couple of problems in the
>> > ap_scan_script_header_err_core()
>> > function. This arose because the response data when it comes back from a
>> > mod_wsgi daemon process just users the CGI way of doing things and so
>> > used that function.
>> >
>> > The first problem was that when WWW-Authenticate headers came back in a
>> > response, the ap_scan_script_header_err_core() function would merge the
>> > values of multiple instances of such headers with a comma in between the
>> > values. As a result, a single header would get returned back to the HTTP
>> > client. As with Set-Cookie header, this would cause problems with some
>> > HTTP clients and they would fail due to the merging. More recent
>> versions
>> > of mod_wsgi therefore no longer use ap_scan_script_header_err_core() and
>> > have had to duplicate what it does so as to prevent merging of
>> > WWW-Authenticate headers.
>> >
>> > The second problem was the size limitation on the values of the headers
>> > coming back from a CGI script. As is, the complete header name and value
>> > must fit within MAX_STRING_LEN (8192). If the size didn't fit under
>> that,
>> > you would from memory get the cryptic error message of 'Premature end of
>> > script header'. In recent times, application such as OpenStack KeyStone
>> > have been generating values for the WWW-Authenticate header which are
>> > larger than MAX_STRING_LEN and so they were failing when used with
>> > mod_wsgi because of the use of ap_scan_script_header_err_core(). In
>> > recent versions of mod_wsgi, the buffer size used to read the header
>> name
>> > and value defaults to 8192, but can be overridden through a
>> configuration
>> > option to allow a larger value to come back.
>> >
>> > So irrespective of where you are going to allow this CGIPassHeader
>> > directive, you might want to look at these other two issues, and if not
>> > both, certainly the issue of WWW-Authenticate being merged as it will
>> > cause issues for some browsers if someone ends up passing back multiple
>> > WWW-Authenticate headers as I am told it can if it supports a choice of
>> > authentication schemes.
>> >
>> > Graham
>> >
>> > On 17 August 2014 06:16, Jeff Trawick <trawick@gmail.com> wrote:
>> > > This core directive would be used to modify the processing of
>> > > ap_add_common_vars() to pass through Authorization or
>> > > Proxy-Authorization as HTTP_foo.  (Nothing else is currently blocked,
>> > > so any other header name wouldn't make sense.)
>> > >
>> > > This directive would be configurable at the directory level, but not
>> in
>> > > htaccess.
>> > >
>> > > Various mods (mod_fastcgi, mod_fcgid, mod_wsgi, etc.) have ways to
>> pass
>> > > this information through; bug 56855 has a patch to add it to
>> > > mod_proxy_fcgi too.  With that patch in place, at least mod_proxy_scgi
>> > > in our tree still couldn't front an app that wants to handle Basic
>> > > auth.  It would be good to consolidate over time the
>> code/documentation
>> > > around suppressing *Authorization.
>> > >
>> > > Some concerns: Processing it in ap_add_common_vars() is not finely
>> > > scoped to natural users of the data; e.g., mod_include and
>> > > mod_ext_filter would see it.  At the same time, not allowing it in
>> > > htaccess may negate its usefulness in some environments.
>> > >
>> > > Thoughts?
>> > >
>> > > --
>> > > Born in Roswell... married an alien...
>> > > http://emptyhammock.com/
>>
>>
>>
>> --
>> >kann mir jemand sagen, was genau @-Domains sind?
>> Ein Mythos. Ein Werbetrick. Verarsche. Nenn es wie du willst...
>>
>>                  -- Alexandra Buss und Björn Höhrmann in dciwam
>>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Mime
View raw message