George,
I think Hoby's response is excellent, but I wanted to
add a few suggestions based on my interpretation of
your problem.
1. If the source address of each of the hosts that
will communicate is known, then you can check for
this using the GetPeerAddr method from within the
SessionAvailable method of TWSocket (I believe this
is exposed in HttpCli as the OnClientConnect event),
and as Hoby suggested, abort the connection if the
address does not match.
Obviously, this will bind your application to those
specific addresses, so if they ever changed you'll
need to make sure to update the validation values.
Also, as Hoby mentioned, you must bear in mind that
the source IP address can be spoofed, so depending on
the criticality or exposure of your application, you
may not want to trust it.
2. Authenticate the incoming request by using one of
the common mechanisms supported by HttpCli. This
still means that the connection needs to be accepted,
and actively rejected if it failed authentication.
One last note: Under no circumstances trust any
information available on the HTTP request/response
header for validation or authenticity (IP address,
referrer, content-type, etc.); these are very trivial
to forge. For most HTTP appliations, this is
normally not a problem, as long as they do not expect
any of those values to contain critical information
that could affect the behaviour of the system.
-dZ.
--
DZ-Jay [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
>------- Original Message -------
>From : Hoby Smith[mailto:[EMAIL PROTECTED]
>Sent : 12/4/2007 12:05:56 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Webserver only with
local connections
>
>George...
Fundamentally, there are really only two ways to
constrain inbound
connections regarding client identification. As I am
sure you are aware,
keep in mind that neither TCP nor HTTP have any built
in mechanisms for
facilitating client identification or rejecting
connections based on any
rules. As a result, it is irrelevant what address /
port you "listen" on,
as TCP will always attempt to allow the connection
initially, unless a
firewall or something else between the host and
server prevents the process.
It is up to you then to reject any unwanted connect
attempts at some point.
Given this, you must address the issue in either or
both of the following
areas:
1. Client origin or source of connection
If you wish, you may determine the client's origin
and reject the connection
based on that origin. The TWSocket components give
you this ability at the
session level. The standard TCP stack has no
mechanism to do this until
after the session is actually arbitrated, so by
default you must accept the
connect (at least partially into the cycle), then
reject the connection,
once you have determined that you wish to do so.
So, if you wanted to constrain the source address of
the client to a local
or specific address only, you could provide some
functionality in the
OnClientConnect event that determines the connecting
source address and
rejects the ones you don't want, such as if it is not
in the local address
space. Bear in mind that the local address space
could originate from the
local loopback (127.0.0.1), as well as one of the
local NIC addresses as
well.
For example, you could use,
TMyHttpConnection(Client).GetPeerAddr, to get
the client's address and then determine if you want
to disconnect it. You
would have to provide this logic and any rules as you
need.
Also, bear in mind that the source address can be
compromised through
various attacks. PPTP and other forms of tunneling
attempt to prevent those
kinds of issues (such as with VPNs implementations).
2. Some form of secure authentication that should be
at least moderately
trustable.
If I understand your need correctly, you are saying
that you DO want to
allow connections from other IP subnets, you just
want to know if they are
from you or something else. To accomplish this, you
need to support some
form of authentication, because there is NO inherent
ability in TCP or HTTP
to tell you this. This is what you are really
looking for. Regardless of
the source of origin, you are really trying to ask
the question, "Is this me
or someone else"? Right? If so, the only solution
is to use some form of
authentication to determine this.
I personally don't use HTTP much because it is so
weak in this regard; in
that, it has no native ability to support
authentication. As a result, you
must address authentication very high up the stack,
on top of protocols that
understand nothing about security or authentication.
However, there are several mechanisms for performing
authentication over
HTTP. I would suggest that you look at the ICS demo
app "WebServ". It
appears to be handling the authentication you are
looking for and should
have the code examples you are looking for.
Then, after you successfully authenticate the client,
the next challenge
comes in determine appropriate types of content
requests to redirect. You
said that you wish to just allow "Flash". You can
only assume certain
things based on port and content, but you cannot be
certain of any of them,
really. Ultimately, what you are trying to create is
a secure proxy that
allows you to redirect, modify or respond as you
need. At this point, you
must determine the appropriate content to pass or
not. I think doing so is
much more complicated than I would want to describe
here, even if I wanted
to attempt it, assuming I understood enough to do so.
However, maybe
someone else has some simple solution to this need.
Anyway, sorry for the long post. I am not the HTTP
guru, by any means.
However, I believe the basic TCP / HTTP concepts I
described should at least
point in some direction? Also, anyone is welcome to
correct me, if I am
missing something or misunderstand something here.
Regards...
Hoby
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
