> back in the days there was a security bug in CFHTTP where
> you could 'control' the IP that was reported in the CGI vars.
That would be purely dependent on your web server, even if there were a way
to write a specific header. I don't remember this, and I would be very, very
surprised if any major, commonly-used web server EVER relied on the HTTP
application protocol layer to provide the IP address of the remote user.
You can, of course, send whatever headers you want via CFHTTP or any other
HTTP client, but that doesn't mean that servers will use or respect them in
any way.
> If someone is watching the TCP/IP traffic and decoding it.
> SSL will hide it (to a point). Having a var passed from the
> app to the web service as an authentication var woul be just
> an extra level of security but is really security through
> obscurity. Something that people just can't see, but once
> known, is useless.
I don't see how that makes any difference in the situation that you were
describing. If I'm sending an HTTPS request to your web service (or any web
server interface for that matter) and you're sending an HTTPS response, I
can see everything within the request and the response. SSL/TLS only keeps
third parties from seeing the traffic between the two endpoints. Either
endpoint can see everything, or it wouldn't be very useful. So, as a
security measure to keep someone from using brute force to determine a valid
username and password, SSL is useless. In fact, as I mentioned, it may
interfere with enterprise-wide monitoring tools looking for just such
brute-force attacks, unless the monitoring tools are installed on (or
behind) the server receiving the HTTPS traffic.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
