Re: XML, PBM and Refugee Scheme

From: "Talisman Games" <jon@paladin.net>

Date: Mon, 12 Mar 2001 02:02:04 +0000

Interesting arguments all...  However, I think our terminology is not in
sync.  My process servers only trust my front-end.  That front-end can be a
web application (HTML, ASP or HTML, Applet, Servelet).  I don't develop
anything currently that installs on the player's computer.  We tend to lean
the Microsoft way - so we code with VB, ASP, HTML.

While it would certainly be possible to submit actions from some other
source to my server, the firewall would simply throw the stream away.  The
firewall only allows the virtual TCP/IP address of the farm to get past it
and only on port 80.  The ASP page talks to an MTS object (which has its own
user id and access parameters) which talks to the database.  The SQL Server
is multi-homed, but switches protocols.  The back-end is on its own hub,
with a different non-routable TCP/IP address range.

While I agree that having players write tools to assist in game play is a
good thing, I still do not want to write a validation loop for them.  You
are correct when you say manpower is limited!!!

I don't think our positions are that far apart.  My front-end is on a
"server", and all validation happens on the "server".  A player tool can
simply call my front-end under the covers and make this work.  My process is
also on a server (several in fact).  I think I was a little too loose with
the term "server".  Our setup looks like this:

Client Browser --(HTTP)->  Web Server (IIS, MTS; HTML, ASP, VB 6) --(ADO)->
SQL Server 7.0 <-(ADO)-- Process Servers(s).

The Web Server(s) are a web farm running WLBS.  The Process Server(s) are
designed to run in groups, so you could have 5 running turns, 2 running
combats, etc.

Thanks for your input, sorry if I misled you.

Jon.

"Paul Walker" <arafel@spamcop.net> wrote in message
news:slrn9ani5r.emm.arafel@nova.blacksun.org.uk...
> On Sat, 10 Mar 2001 16:32:51 -0600, Talisman Games wrote:
>
> >I think you both have gone off on a tangent or more likely, I have not
made
> >myself clear.  We always do validation, but we prefer to do it on the
> >front-end.  You both assumed that the player would create tools to submit
a
> >turn.   I can not imagine why you would allow something like this.  In
our
> >games, we allow a data "feed" for users developing their own tools, but
we
> >never allow anything to come back to the server except through our own
> >front-end.
>
> I think you've missed my point; probably I didn't state it properly.
>
> If I'm reading your posts correctly, currently you have servers that trust
> your front-end software, running on the users machines, to do any required
> validation? So these servers will assume any command that gets passed back
> has already passed the required checks, etc.
>
> This is incredibly unsafe. You cannot afford to trust anything coming back
> from a user, whether it appears (note *appears*) to have come back from
your
> front-ends or not.
>
> If something is running on a user's machine, they have ultimate access to
> it. They can, for example, reverse-engineer the formats used to build up
> their own command packets; sniff the line to create their own transmitters
> which impersonate your front-ends; spy on the memory operations it does.
The
> user has ultimate power over their machine, and yet you're trusting some
> software, running *on* their machine, to give you 'good' commands.
>
> Imagine an online bank account which executed Javascript to validate
> commands - if the browser sent back "yep, he's just deposited 10,000
> pounds", that's no indication people actually *have*. Since it's running
on
> the users machine, in their browser, it's totally insecure. It's madness.
>
> I know there are people on this newsgroup who are almost certainly capable
> of making fake packets for your servers to accept - and this newsgroup is
a
> relatively small sample of PB[e]M people.
>
> I don't think I'm explaining this very well; maybe others can. I see David
> desJardins (spelling?) has also replied. But failing that, read some
> security texts - it's a basic principle that you can't trust anything from
> outside.
>
> --
> Paul
>
> Allow me to introduce myselves.

References

XML, PBM and Refugee Scheme
MindShift Design <teammsd@mindshiftdesign.com>
Tue, 31 Oct 2000 16:02:52 +0000
Re: XML, PBM and Refugee Scheme
"KC Satyr" <sbrown79@kc.rr.com>
Wed, 01 Nov 2000 01:54:22 +0000
Re: XML, PBM and Refugee Scheme
"Enno Rehling" <schick.mir.spam@gmx.de>
Wed, 01 Nov 2000 09:12:13 +0000
Re: XML, PBM and Refugee Scheme
Tim Lomas <tim@nospam.antsnest.demon.co.uk>
Tue, 31 Oct 2000 18:14:14 +0000
Re: XML, PBM and Refugee Scheme
"Talisman Games" <jon@paladin.net>
Fri, 09 Mar 2001 14:38:47 +0000
Re: XML, PBM and Refugee Scheme
"Enno Rehling" <schick.mir.spam@gmx.de>
Fri, 09 Mar 2001 18:34:01 +0000
Re: XML, PBM and Refugee Scheme
"Talisman Games" <jon@paladin.net>
Sat, 10 Mar 2001 14:15:36 +0000
Re: XML, PBM and Refugee Scheme
"Talisman Games" <jon@paladin.net>
Sat, 10 Mar 2001 22:32:51 +0000

Referenced By

XML, PBM and Refugee Scheme
MindShift Design <teammsd@mindshiftdesign.com>
Tue, 31 Oct 2000 16:02:52 +0000
Re: XML, PBM and Refugee Scheme
"KC Satyr" <sbrown79@kc.rr.com>
Wed, 01 Nov 2000 01:54:22 +0000
Re: XML, PBM and Refugee Scheme
"Enno Rehling" <schick.mir.spam@gmx.de>
Wed, 01 Nov 2000 09:12:13 +0000
Re: XML, PBM and Refugee Scheme
Tim Lomas <tim@nospam.antsnest.demon.co.uk>
Tue, 31 Oct 2000 18:14:14 +0000
Re: XML, PBM and Refugee Scheme
"Talisman Games" <jon@paladin.net>
Fri, 09 Mar 2001 14:38:47 +0000
Re: XML, PBM and Refugee Scheme
"Enno Rehling" <schick.mir.spam@gmx.de>
Fri, 09 Mar 2001 18:34:01 +0000
Re: XML, PBM and Refugee Scheme
"Talisman Games" <jon@paladin.net>
Sat, 10 Mar 2001 14:15:36 +0000
Re: XML, PBM and Refugee Scheme
"Talisman Games" <jon@paladin.net>
Sat, 10 Mar 2001 22:32:51 +0000