From: John B. <joh...@ne...> - 2000-09-22 09:15:24
|
On Fri, 22 Sep 2000, Chris Ridd wrote: > Jim Harle <ha...@us...> wrote: > > Peter, just use $ENV{'REMOTE_ADDR'} to get this. --Jim Harle > > > > Right, but that doesn't do the second part of what Peter wanted - he would > appear to have access controls based on the client's network address, and > so wants the web server to proxy the LDAP connection to the server making > it *appear* that the connection is coming from the machine the user is > running their web browser on. > > I'm not sure that's really something that an application like Net::LDAP can > do, it is more of a firewall/proxy thing. (Insert hand waving here.) There > may be other perl modules you could involve to do this however. > > I'm even less sure that it is a secure thing to do. Can't IP addresses be > faked quite easily in HTTP requests? If so, you've just opened up your > directory to the outside world. Barring application-level authentication or fun things like IP source routing (hopefully turned off on any routers between you and the outside world), the remote IP address (as returned by 'getpeername') is probably the most trustworthy piece of information an application has about who is talking to it *for TCP*. There are caveats here with regard to TCP sequence number attacks - but the basic idea is that you trust your IP routing infrastructure to send data back to that IP address - hence not to an attacker. You don't necessarily trust the data that comes to you *from* that IP address. Hence its OK to authenticate a search based on IP address - its a little more dodgy to authenticate an add/modify/delete since the attacker may not care about the result - they just want the effect of the operation. The upshot of this is that I don't see how an application (perl) can spoof the source IP address of a TCP connection. If you want to proxy privileges I think you need application-level authentication - which LDAP is fortunately quite well provided for. regards, jb |