Re: Connecting remotely - multi tier

From: Cedar Cox <cedarc(at)visionforisrael(dot)com>
To: Bob Kline <bkline(at)rksystems(dot)com>
Cc: Adam Lang <aalang(at)rutgersinsurance(dot)com>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Connecting remotely - multi tier
Date: 2000-11-06 09:34:54
Message-ID: Pine.LNX.4.21.0011031027420.27193-100000@nanu.visionforisrael.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces


This is my point exactly. Our setup is a single Linux server w/ win9x
clients. The users, of course, have accounts on the Linux server.
Because of our simi-open environment, I treat everything outside the
server as the 'world', and also because client machines will eventually be
connected through the internet or some other non-secure route. I guess
the issue is that the middle tier shouldn't allow anything more (as far as
modifying data) then the front end is capable of. The front end would
therefore be a fairly small, limited application. The middle tier is
(should be) in a controlled environment whereas the front end is not.
The front end could be modified (security bypassed, hacked). Middle tier
modification would require hacking of the server on which it resides
before even getting to it, then again, the same with the backend.

Basically, you want to make sure that whatever does security checks is
itself secure. Sounds simple, but look at it this way: If your frontend
does things such as check the format of new data in a field, for example,
the user could hack or bypass the frontend in order to get incorrectly
formatted data into a table. (Paranoid? Yes, that's what security is
for..) This may not sound like a big risk, but then again, this is not an
extremely important check (or is it?). The perhaps proper way would be to
put checks like this in the backend or middle tier so that there is no way
to bypass it. Again, this would mean that most of your work would go into
the backend or middle tier programming, which is perhaps to your advantage
if you want to replace/add another frontend, less work to do. Overall, I
think the expandability and security benefits are worth putting work into
a middle tier or backend programming.

I don't claim to be correct as I am speaking with little experience, but
these are the security issues I see. Thoughts? (..sorry if I rambled)

-Cedar

... Is this thread beginning to discuss a book about database security
that should be read? ;)

On Thu, 2 Nov 2000, Bob Kline wrote:

> On Thu, 2 Nov 2000, Adam Lang wrote:
>
> > But if you are an inhouse developer and the database is only in huse
> > and the client is only in house and the database is not open to the
> > public, do you still have to use development time to build that
> > "middle tier" just so you can roll out an app that uses the company
> > database?
>
> Uh, weren't you the one who originally wondered out loud about the
> danger of your users obtaining direct access to your dbms? Even if you
> weren't, it's not a good idea to assume there are no security issues
> just because you're working inside an intranet.
>
> --
> Bob Kline
> mailto:bkline(at)rksystems(dot)com
> http://www.rksystems.com
>
>

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message waheed rahman 2000-11-06 10:00:34 This is waheed from Dubai
Previous Message jaalaw1 2000-11-05 20:38:00 lo_import: cannot lo_import linux files