Wondering if there will be security issue with code-first and Entity Framework?
It will auto generate the three stored procedures for each table. For example, a table named tblAttachment will have auto generated stored procedures like this:
tblAttachment_Delete
tblAttachment_Insert
tblAttachment_Update
Application user is granted the permission to execute all three stored procedures and also SELECT all the tables.
If hacker got the credential of application user, basically he owns the whole databases since application user could do select / delete / update / insert the records. Should this be concerned? What is the best practice in here?
Related
I'm curious if there is a way for a user to use a view in database A (they have permission to database A) that accesses tables in database B (and/or additional databases they don't have permission to) without the user having access to database B?
My scenario:
We currently have a database (database A) where most of the views are housed. Most users across the team also have access to database A. We are wanting to split out our data tables from database A into their own databases (on the same server). When we do this, of course, the views will break because the tables they access will now be in database B. Since there are so many views, I'm looking for an easier way. My thought was to use database A as the hub for the views and as the views are accessed, permissions are granted to the various databases for the user(s) - without giving them direct access to the other databases.
Thank you in advance.
I think a database role would be better than a database as the container for view access.
It might be easier to delete objects than to move them. A backup-restore can create a copy of the database. Then delete the tables and views that don't belong in each database.
Cutting corners on security or integration can come back to bite. If the tables are distinctly part of different systems, then the views should go with the tables. Security and integration between systems by cross database references will tie all those systems to the same server. (Linked servers would be a performance and DTC nightmare.) We have several "separate" justice applications (e.g., DA, Public Defender, Probation, etc.) that do this. Security is still detailed via the use of database roles for each use. The integration is great, but it's a nightmare to migrate because it's all at once and together. If done correctly (e.g., connections strings to each database), we would be able to move one database at a time and update and test one system at a time. As it is now, it takes a lot of project management and a long time to get everybody ready.
If the tables are part of the same system, then schemas could be an option to segregate them if database roles are to tedious to manage. Is it more work to segregate the objects into databases or schemas than to manage a role?
Also, if you use SSDT db projects, then those cross database references (circular?) can be a pain.
For security, I would suggest a database role for each group that needs access. There is no "magic" database level container just for views. The best you can do is SELECT which includes tables and views. For just views, a script is not hard to create to grant a db role select access to all views in the db. I would not ever use grant select and then a DENY on tables because it can prevent access to table for users that should have access. If one or more schemas are used for the views, a role can be granted SELECT access to the schema. This might be the best option. If the view schema and the objects accessed by the view have the same owner, the ownership chain should allow access via the view to tables. For example, if the "view" schema is owned by "dbo", views in the "view" schema should be able to access tables in the "dbo" schema without the user being granted access to those tables. (I have not tried it.)
It would be nice if there was a second flavor of INSERT, UPDATE, etc. permissions that applied to views only, but there isn't.
I have a SQL Server database project with definition of tables, relations, keys, indexes, security, publish profiles, etc. and I also have an ASP.NET Core MVC project.
The issue is that I would like to use Entity Framework for DML operations but the catch is that I am allowed to use only stored procedures (probably from the security perspective, where application account will have only execution permission on those stored procedures and read only on specific tables).
I found that EF can map .SaveChanges() method to stored procedures via model builder like this example
modelBuilder.Entity<SubjectArea>().MapToStoredProcedures();
From the MS docs https://learn.microsoft.com/en-us/ef/ef6/modeling/code-first/fluent/cud-stored-procedures
It can also generate them with migration command. I am not experienced with migrations, but I would like to only generate the SQL for the stored procedures creation and add this script (which was not run yet) into the SQL Server database project (the workaround is to run migration into separate database and generate scripts from the database into the database project, but it seems not nice).
Is it possible to do it somehow?
I have an application that used to work with membership. Now I switched to identity.
I can see the membership tables, stored procedures and views all over the place. They start with asp.net_<Name of the table>, asp_net_<Name of the stored procedure>, and asp_net_<Name of the view>.
For the identity, all I could find are 5 tables:
AspNetRoles
AspNetUserLogins
AspNetUserClaims
AspNetUserRoles
AspNetUsers
I've searched folders in the database, but I can't confirm whether besides the above 5 tables, identity uses other objects, such as stored procedures or views.
If that's the case, can I just script those tables and the create them in the test database? So that when I try to log in, I don't get an error?
Thanks for helping
I would like to be able to store the tracking tables in a different database the original. For a couple of reasons.
I would like to be able to drop it on demand if I change versions of my application.
I would like to have multiple sync scopes separated by user permissioning.
I am sure through the sqlmetadatastore class there is a way, but I have not found it yet.
the sqlmetaadatastore will not help you in any way with what you're trying to achieve. am pretty sure its not in anyway exposed in the database sync providers you're using.
note that the tracking tables are not the only objects Sync Framework provisioning creates, you will have triggers, tracking tables, stored procedures and user defined table types. and you're not supposed to be dropping them separately or even dropping them by yourself, but you should be using the deprovisioning API.
now if you really want to have the tracking tables on a separate db, the provisioning API has a Script method that can generate the SQL statements required to create the Sync Fx objects.
you can alter that to create the tracking tables on another DB, but you have to alter the triggers as well to insert on this other database.
I am not a security expert and there was a discussion in my project about if we should use Entity Framework. Even though it seems we will use it the project leader is instill insisting that we should still do all our operations (that includes simple CRUDs) with store procedures because of security. He says that if we use stored procedures the users will only need permission for executing a stored procedure instead of needing permissions for create/read/update/delete.
As I said before I am not a security expert, so I was curious to know how true is this.
What this does is give rights and privileges to the individual store procedures, which then have access to the tables, rather than to the tables themselves.
This way you can restrict the users from all the tables, and allow the SPs to allow semantic access based on other logic (both DB permissions at the SP level, as well as code within the SP).
This is gives the overall security framework finer granularity in terms of roles and privileges.
For example, using normal DB permissions, it's easy to limit what tables a user can see, but not what rows they can see within a table.
Two ways to fix that is to limit access to the underlying table, and then create a limited view on that table and grant permission to that, or you can limit access via the SP which has logic capable of restricting what rows a user can see.
Its true.
Stored procedures gives ability to perform better security than standard table permission (for example by giving possibility to update only few columns of table)
But..
For developers its a nightmare. Even simplest query needs to be implemented as stored proc or view.
So its not agile, rapid or sexy :)