[Zope] Apache, mod_rewrite, https working together?

[Jim Penny]

On Thu, Jun 14, 2001 at 03:34:35PM +0200, Ragnar Beer wrote:
> <snip>
> >DocumentRoot /var/www
> >RewriteEngine On
> >RewriteLog "/var/log/apache-ssl/rewrite_log"
> >RewriteLogLevel 0
> >ProxyRequests on
> ><Directory /var/www/dynamic>
> >     RewriteEngine On
> >     RewriteRule ^/var/www/dynamic/(.*) 
> >http://localhost:8080/$1?REMOTE_ADDR=%{RE
> >MOTE_ADDR} [QSA,P]
> ></Directory>
> >
> <snip>
> 
> Does it help much to specify REMOTE_ADDR in the query string? Fortunately
> this doesn't override the internal REMOTE_ADDR so that the correct IP
> gets logged. Otherwise what would stop people from providing a false IP?
> I guess the via-header patch that is mentioned in one of the howtos would
> be a better solution. But I haven't tried it.
> 
> Ragnar
> 

I am going to use:
http://localhost:8080/$1?REAL_REMOTE_ADDR=%{REMOTE_ADDR} [QSA,P]

Note however, that the REAL_REMOTE_ADDR being pushed onto the query string
is the REMOTE_ADDR coming from apache itself, and that it is being pushed
last into the query string. In this sense, it is no worse than the
via_header patch, since it is getting the REMOTE_ADDR data from the
same place (the remote end of the socket).

What happens if a remote user does specify a query string containing
REAL_REMOTE_ADDR?

Testing...

I just tried url
https://myhost/test/?REAL_REMOTE_ADDR=23.23.23.23

This page shows REAL_REMOTE_ADDR as ['172.18.13.13', '23.23.23.23']

This actually gives a test for spoofing attempts.  
If REAL_REMOTE_ADDR[1] exists, we have a crack attempt, which
cn be dealt with appropriately.

Finally, since the manipulation is happening inside apache itself,
the user never sees the query string's key.

So, if you are more comfortable using a rule like

http://localhost:8080/$1?ZSXQWUP2SD=%{REMOTE_ADDR} [QSA,P]

It is OK to do so.  The remote user can see your query string's key
only when he can see <dtml-var REQUEST>, which is under your control.

So...

We can 1) detect query string spoofing, 2) use an arbitrary name, 
3) hide all this from the end user, and 4) guarantee that we have
at least one REAL_REMOTE_ADDR, one that is as good as the via_header.

Looks alright to me.

------------------------------------------------------------------

Another note:

Even if you aren't using this for security, there can be other reasons
to need the remote address.  Suppose you have a service that is mostly 
intranet based, with some extranet users.  Your server is at a martian 
address, and is not in the extranet DNS anyway.  In such a case, you want 
to adjust your URL's depending on whether a user in internal or external.
There is no need to generate firewall traffic for internal users, so
you want to present them with the direct address.  External users
cannot see the direct address, and so have to be presented with a 
proxied (or port forwarded) address.  So, it is very useful to be
able to distinguish whether an Authenticated User is coming from the
inside or outside.

That is, authentication is the process that lets me decide if I should
present a page to the user (at all).  This just gives me another 
clue on _how_ I should present it.

Jim Penny