Security

Ask something
Discussion Locked

Database security

0 helpful
5 replies

by snsdatahub

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Hi,

I've searched the web with little success with the following question, and do hope someone can help shed some light on this issue.

I've been involved in network security for the last couple of years, but have recently included application security as part of my job responsibility.... and hence this question :)

I've been told by my developers that for some of our applications, the following is the framework...

1. user logs on to the application
2. user requests for some info
3.the application will logon to a backend datbase with a system ID and password to retrieve that information. This system ID and password is used by all authorised users to access the backend database.

The question is... Does this constitute a compromise of security? Should each user/password have unique access to the database instead of using a shared user id / password?

Any advise on this?

Thanks!!!

5 replies

by joseph moore

Well, it really depends on how the application your developers have written is structured.
Since your users "1. user logs on to the application", then the app written by your developers obviously has its own user database. Now if in this database, your developers might have imposed access restrictions.
For example, say user BOB has an account in this app. In the user tables in the app, say that BOB has Read access to Table1, Table2 and Table3, but no access to Table4.
Then, when BOB queriesthe back-end database (using the app as his interface with the back end database server), the app probably checks what tables BOB can access and what type of access BOB has.
The app then constructs its query to the back-end database, pulling the appropriate data. Now, in this query, yes the app makes its connection using the standard "system ID and password".
But, all access rights are being monitored and enforces by the front-end app.

So, I would talk to your developers and see if this isthe case. Most likely (if the developers thought of security in ANY WAY) this is how it works.

A lot of applications work like this. There is a user table with user names, password, and rights allowed; then when a connection is made to a back-enddatabase, a standard account is used to do this, but the user table is used to query and retrieve the appropriate info.
Database security is maintained by the front-end app.

hope this helps

by erikdr

Answer 1. is okay but incomplete.
Essential for a construction like this is that SOLELY THIS APPLICATION does have ACCESS to the DATABASE. This can be done e.g. by having TCP/IP security and only allowing the server with the application access to the database node.
The fact that there is a generic 'task id' which has full rights to the database in itself is a compromise of security, UNLESS compensated by network security.

An alternative construction is indeed giving the user id itself access to the database. (Of course based on groups, not separate id's). This too however has its limits - e.g. certain userid's will get SQL permissions to update a salary table, but you REALLY only want them to exercise these rights through the application (with dialogs, validation, signing etc.) and not through straight SQL. Hence in this solution we sometimes recommend adding a 'spying agent' to the ODBC connection which only accepts SQL calls from registered applications.

So in both routes, solid version control and software change management on all involved nodes is essential for security...

Hope this helps,

- The Netherlands

This discussion is closed to new replies.