Database

9-May-07 4:49

Hi chaps,

I've got a question about security. I understand that you don't want a user to be able to trash your database, so parameterised SQL / Stored procs are the sensible way of doing things. But i'm wondering more about permission based security, and at what locations it should be checked.

Lets say you have a web app, you would security check the following at the back end:
* View Record
* Perform Action

But what structure would you put in place to validate functionality on the Layer side of things and catch things further down the chain? Would this have to be performed on a per function basis? In which case, would it prohibit the use of ORM / Full Record Updating and merely refine the database access down to a rigid API?

Cheers

Tris

-------------------------------

Carrier Bags - 21st Century Tumbleweed.

kubben9-May-07 14:35

9-May-07 14:35

Normally you have two choices when you connect to a sql database. Sql user and NT authenticated user. You can do both of these with a web app. Either way you should only have one user. It is in your best interest to have that one user only have rights to execute stored procedures. So if you want to select something, call a stored procedure. If you want to insert update delete something, call a stored procedure. That way if your security gets compromised you limit your exposure since that user can only execute stored procedures. It may seem like more work, but in the end it really makes things a lot more secure and you know exactly what your web site can and can't do since all the code is in the stored procedures.

I am not sure if that answered your question.

Ben

Tristan Rhodes10-May-07 1:49

10-May-07 1:49

Hi Ben,

I'm more interested in providing a security saftey net in each layer of the application. My problem is that, using full table insert / updates, even with stored procs, the only place to reliably catch illegal incoming data (based on permissions), is on post back. In the event of a security loop hole, i'd like to have something that can catch it in the database layer, which would probably involve an ACL, in which case, IF a user has privelages for that particular record, how do you determine that they have for instance, unlocked a locked thread that should be locked.

Cheers

Tris

-------------------------------

Carrier Bags - 21st Century Tumbleweed.

kubben10-May-07 1:56

10-May-07 1:56

Are we talking about database access here or have we moved on to a different subject? The most secure web app to sql access I can think of:
Create a new app pool for your web app.
Create a windows authenticated username and password.
Set the identity of the app pool to be that windows user.
Set your sql server to authenticate via windows authentication only, no sql users and passwords.
Only give stored procedure rigths to that windows user that the app pool runs as.
So at this point there isn't any way that anyone could get the password of that windows user since it isn't stored anywhere. It isn't in the connection string etc.
The web application runs as that identity, but it is just a normal windows user that only has access to stored procedures on the sql server. So at that point I don't know what else you want. It seems pretty secure to me, but then again perhaps I am missing something.

Ben

Tristan Rhodes10-May-07 2:44

10-May-07 2:44

Hi Ben,

Thanks for the reply, but it wasn't a question on securing web apps in the traditional sense, but on a 3 tier architecture where the Database has its own permission table above and beyond an authenticated user.

The Web app would have its security checks, which it determines by querying the DBLayer security functions, then when invoking a function in the DBLayer it would internally query the security functions and if the permissions are not valid, raise an exception. That would make 2 security checks, as opposed to one.

This would however make it difficult to use full table access with raw CRUD, and instead limit any manipulation to fine granularity stored procs.

I was just wondering about the practicality of that.

Tris

-------------------------------

Carrier Bags - 21st Century Tumbleweed.

kubben10-May-07 3:23

10-May-07 3:23

Not very practical. In all the applications I have done recently we have several layers. The bottom line is still the same. In some layer you have a connection string to the sql database. You really have two options for that connection string, sql user and nt authentication. You have modes you can run your sql server security in. Mixed allowing both windows authentication and sql users and only windows authentication. This is where your security is. I don't know what you would try to add your own second check on security on top of that. If you have an avoidance to using only stored procedures to improve your security because you think it is too much work, in the end you are making more work by trying to add your own security and it probably won't be that much more secure.

I would go with what sql server can provide you since that is what most people are doing. That way when someone has to support code you have written, they can understand quickly how the securty works, verses they need to learn this custom system you wrote that will probably be a nightmare to support.

Ben

Tristan Rhodes10-May-07 3:47

10-May-07 3:47

Hi Ben,

Using an ACL, authenticated and authorised users could both view / edit / delete, however, normal users can only edit / delete their own unlocked records, not edit / delete someone elses records, OR their own records if they are locked, and an admin user could do anything.

Alternatively, a normal user could not Lock / Unlock any records, wheras an admin user could.

Therefore, merely being authorised on the top level via windows / db security would not be enough to stop a logged in user from deleting any records, and further permission checking would be required.

This isn't about the ability to access the database, but the ability to restrict certain sets of functionality on the database whilst logged in. I am already using a role based system, but was looking to make it slightly deeper than just testing the user roles when recieving a HTTP request.

The problem here is that, if a table contains certain fields that only an admin user should be able to change, and i am running a full record CRUD system (I think thats table direct), it would be an easy matter to enable a normal user to perform admin tasks by mistake, and not have a way to test this via permissions.

-------------------------------

Carrier Bags - 21st Century Tumbleweed.

kubben10-May-07 3:51

10-May-07 3:51

If you are talking about a web application your web app would have to be internal only NOT on the internet if you wanted it to use windows authentication. I would still choose to use a forms base authentication which means your web app has one identity for all. If you have one identity you don't have the issues you are talking about above since you can very clearly control what access that web app identity has.

If you are talking about a windows app, sure things can be different, but you should approach windows and web app differently.

Ben

Tristan Rhodes10-May-07 4:46