SqlCommand - 防止其他数据库中的存储过程调用
当使用SqlCommand通过RPC调用存储过程时,看起来可以调用当前数据库以外的数据库中的存储过程。
例如:
string storedProcName = "SomeOtherDatabase.dbo.SomeStoredProc";
SqlCommand cmd = new SqlCommand(storedProcName);
cmd.CommandType = CommandType.StoredProcedure;
我想通过禁止对另一个数据库的潜在调用来使我的 DAL 代码更具限制性。一种方法可能是检查上面的storedProcName中是否有两个句点(点),如果有,则抛出异常。还有其他想法/方法吗?
谢谢。
When using SqlCommand to call a stored proc via RPC, it looks like it is possible to call a stored proc in a database other than the current database.
e.g. :
string storedProcName = "SomeOtherDatabase.dbo.SomeStoredProc";
SqlCommand cmd = new SqlCommand(storedProcName);
cmd.CommandType = CommandType.StoredProcedure;
I'd like to make my DAL code more restrictive, by disallowing potential calls to another database. One way might be to check if there are two periods (dots) in storedProcName above, and if so, throw an exception. Any other ideas/approaches ?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
通常此类限制是在服务器端配置的。
SQL Server 具有非常广泛的安全模型,允许它通过向特定“主体”(用户或组)授予特定数据库对象(表、视图、存储过程、架构...)
您建议让 DAL 层应用一些限制,以防止在与 ADO 连接关联的默认数据库之外使用存储过程,这表明了对于“发送到 SQL”的内容采取了积极主动的态度”。一般来说,这是一种有价值的态度(例如防止 SQL 注入),但在这种情况下,我建议不要这样做:
如果将来某个时候需要特定的“外部”存储过程怎么办?另外,如果当前数据库上有多个存储过程应该禁止应用程序使用(因为它们仅用于维护/数据加载/审核/其他任何内容)怎么办?通过引入一些 DAL 级别限制,您可能会在以后遇到困难,并且可能会导致您相信访问控制是足够的,但事实可能并非如此......
Typically such restrictions are configured on the server side.
SQL Server has a very extensive security model which allows it to provide very granular access by granting specific permission ("Read", "Write" and such) to specific "Principals" (Users or Groups) for specific database objects (Tables, Views, Stored procedures, schemas...)
Your suggestion of having the DAL layer apply some restriction to prevent the use of stored procedures outside of the default database associated with the ADO connection shows a pro-active attitude with regards to what is "sent to SQL". In general this is a valuable attitude (for example to prevent SQL injection), but in this case, I'd advise against it:
What if at some point in the future a particular "external" Stored Procedure is needed? Also, what if there are several stored procedures on the current database which should be off-limit to the application (because they are only for maintenance/data-loading/audit/whatever-else) ? By introducing some DAL level restrictions you may be setting up yourself for difficulties at a later time, and you may be led to believe that the access control is adequate which it probably isn't...
您的数据库中可能存在名称中带有点的过程:
正如 Hallie 所说,您最好充分保护服务器(不要在其他数据库中为 SqlConnection 使用的任何帐户授予任何权限)。
另外,如果您正在处理 2005 或 2008 数据库,则当前数据库中可能有一个同义词实际上引用了另一个数据库,或者当然,当前数据库中的任何存储过程都可能调用另一个服务器/数据库中的存储过程。
因此,基本上,控制您的数据库服务器(控制创建哪些对象以及授予哪些权限),并编写更少的代码来尝试覆盖服务器现在可以充分响应的情况。
There could be procedures in your database with dots in their name:
As hallie says, you're better off with adequately securing the server (not granting any permissions in other databases for whatever account is being used by the SqlConnection).
Also, if you're dealing with a 2005 or 2008 database, there could be a synonym in your current database that actually references another database, or of course, any stored procedure in the current database may call a stored proc in another server/database.
So basically, take control of your database server (control what objects get created, and what permissions are granted), and write less code trying to cover cases which the server can now respond to adequately.