Authentication method for web app

On 05/13/10 09:21, Leonardo F wrote:

Hi all,

we're going to deploy a web app that manages users/roles for another
application.

We want the database to be "safe" from changes made by malicious
users.

I guess our options are:

1) have the db listen only on local connections; basically when the
machine is accessed the db could be "compromised". Hardening the
server access is the only true security defense we have.

2) Use, as user/password, the same user/password used to
enter the web app. Basically there would be a 1 to 1 matching between
our app users (and password...) and the db users (with proper
permissions...)

I'm not a great expert on these things (as you've already guessed...).

Can someone help me?

As you already figured out, the key is protecting both the application
and the db server from intrusions. If anyone gets unauthorized access to
either of them, especially if it's root access, any and all security you
build on top of that will in all likelihood collapse.

Personally I would lean toward making the bulk of security within the
application so to simplify everything - the database would do what it
does best - store and manipulate data - and the application would be the
single point of entry. Protect the servers - keep the applications (like
ssh, php, apache, your application) updated and make sure you have good
and frequent backups.

Personally I would lean toward making
the bulk of security within the
application so to simplify everything - the
database would do what it
does best - store and manipulate data - and the
application would be the
single point of entry. Protect the servers - keep
the applications (like
ssh, php, apache, your application) updated and make
sure you have good
and frequent backups.

Thank you for your reply.

Anyone else? How do you "secure" your db used by
webapps?

On 14 May 2010 09:08, Leonardo F <m_lists@yahoo.it> wrote:

Personally I would lean toward making
the bulk of security within the
application so to simplify everything - the
database would do what it
does best - store and manipulate data - and the
application would be the
single point of entry. Protect the servers - keep
the applications (like
ssh, php, apache, your application) updated and make
sure you have good
and frequent backups.

Thank you for your reply.

Anyone else? How do you "secure" your db used by
webapps?

Basically what I've said:

1) find all points of entry to the db (i.e. the application), secure them
2) keep the server itself secure (applications patched, firewall
enabled with custom rules to protect the db if necessary, only trusted
local users etc.) If the app and the db are on different servers,
consider a direct (patch cable) link between them or if the structure
is more complex a switch, remove them from Internet, possibly make a
DMZ, etc.

On Fri, May 14, 2010 at 4:43 AM, Ivan Voras <ivoras@freebsd.org> wrote:

On 14 May 2010 09:08, Leonardo F <m_lists@yahoo.it> wrote:

Personally I would lean toward making
the bulk of security within the
application so to simplify everything - the
database would do what it
does best - store and manipulate data - and the
application would be the
single point of entry. Protect the servers - keep
the applications (like
ssh, php, apache, your application) updated and make
sure you have good
and frequent backups.

Thank you for your reply.

Anyone else? How do you "secure" your db used by
webapps?

I would avoid using a 1-to-1 for web users having access to the db. Keep
your database server secure, and keep your connection info inside the app.
Look at it this way:

If you properly secure the system, the chances of a malicious user
getting access to the DB are pretty slim, if you do the '1-to-1' that you're
talking about, you've effectively given the keys to your database to
everyone who can get an account.

Basically what I've said:

1) find all points of entry to the db (i.e. the application), secure them

2) keep the server itself secure (applications patched, firewall
enabled with custom rules to protect the db if necessary, only trusted
local users etc.) If the app and the db are on different servers,
consider a direct (patch cable) link between them or if the structure
is more complex a switch, remove them from Internet, possibly make a
DMZ, etc.

I think this point number 2 is pretty important. If at all possible, keep

the webapp separate from the database, and keep the database server on a
fairly restrictive firewall. This means that someone has got to get in to
the webapp, then hop to the database server, it just adds another layer of
mis-direction for any would-be evil doers.

Make sure to have a well thought-out pg_hba.conf, many people overlook this
step in favor of a less-headachy

host all all 0.0.0.0/0 md5

Line. The above says "Let everyone connect to everything from everywhere
with a password". Even if your database is behind a firewall, Be Explicit
with your access controls:

host webuser prodDb 192.168.30.12/32 md5
host devuser prodDb 10.1.1.5/32 md5

etc....

Don't give it all away.

At the same time, restrict the number of users in your organization that
have ssh access to the machine. My experience (even with developers) is
that given the chance, they will create a password that = their username, or
something even dumber, and the box WILL get hijacked. Keep remote console
access isolated to a few people that understand the stakes.

Good luck

--Scott

I think this point number 2 is pretty important. If at all possible, keep
the webapp separate from the database, and keep the database
server on a fairly restrictive firewall. This means that someone has
got to get in to the webapp, then hop to the database server, it just
adds another layer of mis-direction for any would-be evil doers.

Which are the authentication methods "recommended" in this
scenario? It sounds to me that no matter the auth mechanism,
if a user can connect to the webapp server with the user that runs
the webapp there's no way of avoiding the connection to the db
(since the user will then be free to see/do whatever the webapp was
seeing/doing).

________________________________

From: pgsql-general-owner@postgresql.org on behalf of Leonardo F
Sent: Fri 14/05/2010 14:24
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Authentication method for web app

I think this point number 2 is pretty important. If at all possible, keep
the webapp separate from the database, and keep the database
server on a fairly restrictive firewall. This means that someone has
got to get in to the webapp, then hop to the database server, it just
adds another layer of mis-direction for any would-be evil doers.

Which are the authentication methods "recommended" in this
scenario? It sounds to me that no matter the auth mechanism,
if a user can connect to the webapp server with the user that runs
the webapp there's no way of avoiding the connection to the db
(since the user will then be free to see/do whatever the webapp was
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Here is my 2 pence:

There are 2 types of security in computer. Physical and non-physical.

You are correct in saying that if someone were to get the user credentials of the user that the web app runs under, then they could access nearly everything that the web app could see. You then have to decide how to protect those credentials. Your web app should never disclose them, and a person should not give them out.

Bottom line, secure your server physicall, as well as logically. Don't give the web app users password out, don't give it a login shell etc..etc..

If you build a web-app the user doesn't connect to the db . It connects
to the application.
It is the web app that should have an auth mechanism.
The web app will perform predefined and limited operations and it is the
web programmer that has to guarantee that only operations provided by
the web application can be performed by web app user.
In an e-commerce web application when the user places an order doesn't
execute an insert sql statement. Is submits a form an the form is
processed in the web application.
Let say orders can be placed only by registered users, is the web
application that has to allow login and check that the user is
authorized throughout the order process.
This is business logic and it's hard to believe you want to place
business logic in the db.
Moreover you will tipically use a connection pool and not create single
connections not to risk to overload your db. Hence you have to create
the pool and provide db user credential at that time, not when the user
connect to the application.

I suggest you read something about developing multi-tiered applications
and the MVC pattern before going further.

Once done that you can chose a web application development framework:
many of them provide authorization mechanism or allow you to plugin your
preferred one

Il 14/05/2010 15.24, Leonardo F ha scritto:

I think this point number 2 is pretty important. If at all possible, keep
the webapp separate from the database, and keep the database
server on a fairly restrictive firewall. This means that someone has
got to get in to the webapp, then hop to the database server, it just
adds another layer of mis-direction for any would-be evil doers.

Which are the authentication methods "recommended" in this
scenario? It sounds to me that no matter the auth mechanism,
if a user can connect to the webapp server with the user that runs
the webapp there's no way of avoiding the connection to the db
(since the user will then be free to see/do whatever the webapp was
seeing/doing).

--
==================================================
dott. Ivano Mario Luberti
Archimede Informatica societa' cooperativa a r. l.
Sede Operativa
Via Gereschi 36 - 56126- Pisa
tel.: +39-050- 580959
tel/fax: +39-050-9711344
web: www.archicoop.it
==================================================