胖客户端访问的安全 SQL Server

发布于 2024-09-11 23:06:33 字数 231 浏览 8 评论 0原文

有没有办法保护胖客户端访问的 SQL Server 数据库的安全？含义：应用程序在放置 sql 语句时直接与数据库通信。这意味着，连接字符串必须位于客户端的某个位置。使用此连接字符串（使用 winauth 或 sql server 身份验证），任何用户都可以使用某些 Management Studio 或命令行访问数据库，并向数据库放置与 GUI 允许的不同的语句。
对此该怎么办？我无法在客户端和数据库之间放置另一层，因为此架构已修复。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

未蓝澄海的烟 2024-09-18 23:06:33

这就是 SQL Server 权限的用途。

您可以执行一些操作，例如向用户授予对视图或存储过程的权限，而不向用户授予对基础表的权限。

您可能想查看应用程序角色

http://msdn.microsoft.com/ en-us/library/ms190998.aspx

http://www.sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/" sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/

回复收藏 0 原文

套路撩心 2024-09-18 23:06:33

在所有安全模型（包括 Windows 和 SQL 身份验证）中，访问权限均授予用户（身份），而不是应用程序。因此，应用程序所需的任何访问权限必须授予运行该应用程序的用户。当使用 Windows 身份验证时，这意味着同一用户可以通过 SSMS 查询利用应用程序本身所需的所有权限。这是任何管理员都必须理解的基本规则。从安全的角度来看（意味着诸如 CC 合规性等），这是事实，任何规避它的尝试都是注定要失败的。

但从实际角度来看，有一些措施是可以采取的。最常用的一种是使用登录触发器来验证APP_NAME() 并允许访问SSMS 仅来自一组明确定义的客户端工作站，并且适用于一组明确定义的用户。

CREATE TRIGGER reject_SSMS
ON ALL SERVER WITH EXECUTE AS '...'
FOR LOGON
AS
BEGIN
IF (APP_NAME() = 'Microsoft SQL Server Management Studio' 
   OR APP_NAME() = 'Microsoft SQL Server Management Studio - Query')
   AND (ORIGINAL_LOGIN() NOT IN (...)
   OR HOST_NAME() NOT IN (...))
    ROLLBACK;
END;

重要的是要了解此类机制不是安全功能，因为它们很容易被恶意用户规避。它们更像是门锁：它们不能阻止小偷，而是让诚实的用户保持诚实。

In all security models, including Windows and SQL Authentication, access rights are granted to an user (an identity), not to an application. therefore, any access right needed by the application must be granted to the user running the application. When Windows authentication is used this means that the same user can leverage all the privileges needed by the application himself, from an SSMS query. This is a fundamental rule any administrator must understand. From a security point of view (meaning things like CC compliance and such) this is a fact and any attempt to circumvent it is doomed.

But from a practical point of view, there are certain measures that can be deployed. The most commonly used one is to use a logon trigger that validates the APP_NAME() and allows access for SSMS only from a well defined set of client workstations, and for a well defined set of users.

CREATE TRIGGER reject_SSMS
ON ALL SERVER WITH EXECUTE AS '...'
FOR LOGON
AS
BEGIN
IF (APP_NAME() = 'Microsoft SQL Server Management Studio' 
   OR APP_NAME() = 'Microsoft SQL Server Management Studio - Query')
   AND (ORIGINAL_LOGIN() NOT IN (...)
   OR HOST_NAME() NOT IN (...))
    ROLLBACK;
END;

What is important to understand that such mechanisms are NOT security features, as they can be easily circumvented by a malevolent user. They are more like door locks: they don't keep thieves out, they keep honest users honest.

回复收藏 0 原文

感性 2024-09-18 23:06:33

首先也是最重要的 SQL 注入漏洞的全部要点是攻击者能够操纵查询。这个有目的的协议是一个更严重的漏洞。但不仅如此，这也明显违反了 CWE-602：客户端执行服务器端安全性和CWE-603：使用客户端身份验证< /a>.

为了确保安全，您必须执行以下操作：

每个用户还必须拥有自己的锁定数据库。因为他们只有选择/更新/删除/插入，没有其他权限（尤其不是 xp_cmdshell()!!!!!）。您不能允许用户共享数据库，否则攻击者将能够查看其他用户的信息。攻击者始终能够获取 sql 服务器的用户名/密码，并能够直接与自己的客户端连接。很难认为这种关系是安全的，几乎在所有情况下，这都是巨大的脆弱性。

实际上，这是一个非常严重的架构缺陷，您必须构建一个服务器端组件来为客户端构建需求。这通常使用 SOAP（针对 ms 平台的 wcf）来完成。

回复收藏 0 原文

~没有更多了~