Thread: Authentication method for web app

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?


Thank you

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.

>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).

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
==================================================