标签: security

像 sa 这样的已知帐户名是否对数据库构成安全威胁？在 SQL Server 上使用 Windows 身份验证时，它是否强加了相同的密码策略（如果设置为 5 次后帐户锁定）？

最近我一直在使用 EXECUTE AS LOGIN 来检查某个人是否可以或不能在我们的一个数据库中使用表函数。测试表明他可以，但他一再报告失败。

该人使用登录“WEB”连接到数据库，并且他在该数据库中拥有与登录“WEB”关联的用户“WEB”，因此我尝试了以下脚本：

-- part 1
EXECUTE AS USER = 'WEB'
GO
SELECT 
    USER_NAME() AS 'user_name'
    ,SUSER_NAME() AS 'suser_name'
    ,SUSER_SNAME() AS 'suser_sname'
    ,SYSTEM_USER AS 'system_user'
GO
REVERT
GO

和

-- part 2
EXECUTE AS LOGIN = 'WEB'
GO
SELECT 
    USER_NAME() AS 'user_name'
    ,SUSER_NAME() AS 'suser_name'
    ,SUSER_SNAME() AS 'suser_sname'
    ,SYSTEM_USER AS 'system_user'
GO
REVERT
GO

第一部分很好，结果如下：

网站 | 网站 | 网站 | 网络

但是第二个结果有点令人困惑：

dbo | 网站 | 网站 | 网络

EXECUTE AS USER 和 EXECUTE AS LOGIN …

我被要求为数据库中的所有表授予SELECT,INSERT和UPDATE给定用户。我最终将用户添加到db_datareader，并给予他们INSERT与UPDATE在数据库级别。

但这让我想到，SELECT在数据库级别授予用户权限或将它们添加到db_datareader角色之间有什么区别（如果有）？是否有任何一种或另一种最佳实践？

我偶尔会看到一些问题，询问如何安全地存储 Web 应用程序的用户密码（使用 RDBMS，我不是在谈论 Facebook 或 Twitter）。通常的答案是“对密码加盐，然后使用 TDES 或 SHA512 等强算法对其进行散列”。

我的问题是：作为 RDBMS 用户，我为什么要为密码存储问题而烦恼，因为大多数引擎都有内置的身份验证机制。

例如，如果某个用户 X 想要在我的 Web 应用程序上创建帐户用户密码 Y，那么发出以下查询是如何错误的：

CREATE USER X WITH ENCRYPTED PASSWORD Y IN GROUP baseuser;

然后在我的应用程序中，用户可以使用他的凭据打开与数据库的连接，而我根本不必费心管理密码。

我看到了这种方法的多个优点：

• 如果 RDBMS 决定需要更改加密算法，我不需要接触任何东西，只需应用安全更新；
• 我很容易管理用户授权。如果用户被提升为管理员角色，我只需要将该用户添加到相应的组中即可；
• SQL 注入现在毫无意义，因为我管理权限以允许我想允许数据库中的每个用户（例如，在像 SO 这样的论坛中，添加新帖子，回复帖子，评论和编辑/删除他自己的问题） /答案/评论）；
• “匿名”用户帐户可用于未经身份验证连接到我的应用程序；
• 每个用户都是他提供的数据的所有者。

但在我看到的关于这个主题的几乎每个问题上，似乎都有一个普遍的共识，即这不是必须做的事情。我的问题是：为什么？

注：第三点是允许的政策在PostgreSQL和安全政策在Microsoft SQL Server。我意识到这些概念是新来的，但无论如何，既然它们已经出现，为什么我描述的技术没有成为处理用户帐户的标准方法？

所以我试图在我的 Microsoft SQL Server Management Studio 2019 中更改一些设置。我将登录模式从混合（Windows 和 SQL 身份验证）更改为仅 Windows，现在我无法使用我的 sa 帐户登录，我没有拥有另一个具有管理员权限的帐户。

我该怎么办？任何建议将不胜感激。

大多数 SQL 注入的答案和示例都显示某种形式的动态 SQL 或将参数解释为 SQL。

我还没有找到“正确”方式的例子。Microsoft 和 Oracle 的文档仅显示了不应做什么的示例。

因此，我想我应该询问这个存储过程示例是否受到 SQL 注入攻击的保护。

CREATE PROCEDURE test
    @username = varchar(30)
    @password = varchar(30)
AS
BEGIN
    SELECT *
    FROM credentials
    WHERE username = @username
    AND password = @password;
END
GO

这个特定的过程是否容易受到 SQL 注入的影响？我创建了该过程并通过各种尝试注入 SQL 来执行它，例如EXEC test @password = '0; drop table credentials;'，但无法这样做。我想我可能没有正确地进行攻击。

我无法使用 SQL Server 身份验证登录到 SQL Server 2008。

我只能使用 Windows 身份验证模式登录。

我在安装 SQL Server 2008 R2 时只选择了默认值。

我有一个 Windows 终端服务器，其中有许多不同的用户通过 RDP 登录以运行应用程序。该应用程序为每个用户建立一个或多个到 SQL Server 2008 R2 实例的连接。所有用户使用相同的 SQL 登录访问相同的数据库。我希望能够跟踪特定用户的 SQL 会话，但我还没有找到确定哪个 SQL 会话属于哪个用户的方法。但是，我能够确定应用程序的每个实例正在使用的源 TCP 端口。

有没有办法根据客户端的 TCP 端口跟踪 SQL 会话？

TRUSTWORTHY如果您不小心，该设置可能会相当危险，除特定情况外，建议将其关闭。但是默认情况下，MSDB数据库TRUSTWORHTY设置ON默认。我很好奇为什么？

我已阅读BOL 中的此条目

注意默认情况下，MSDB 数据库的 TRUSTWORTHY 设置设置为 ON。更改此设置的默认值可能会导致使用 M​​SDB 数据库的 SQL Server 组件出现意外行为。

但我对具体情况很好奇。为什么具体MSDB需要TRUSTWORTHY开启？什么功能使用它？

所以我最近转移了工作——我在我们的新 SQL Server 安装的构建脚本中发现的一段代码如下。

IF EXISTS ( SELECT  *
            FROM    [sys].[syslogins]
            WHERE   [name] = N'NT AUTHORITY\SYSTEM' )
    BEGIN
        DROP LOGIN [NT AUTHORITY\SYSTEM];
    END

IF EXISTS ( SELECT  *
            FROM    [sys].[syslogins]
            WHERE   [name] = N'NT SERVICE\SQLWriter' )
    BEGIN
        DROP LOGIN [NT SERVICE\SQLWriter];
    END

IF EXISTS ( SELECT  *
            FROM    [sys].[syslogins]
            WHERE   [name] = N'NT SERVICE\Winmgmt' )
    BEGIN
        DROP LOGIN [NT SERVICE\Winmgmt];
    END
GO

默认情况下，这些帐户是在 SQL Server 安装过程中创建的。

是否建议删除上述登录？这会导致任何副作用吗？这些登录有什么用？

我阅读了能否删除 NT SERVICE\SQLWriter 和 NT SERVICE\Winmgmt 登录名？但这还不够具体-我可以看到它们的用途，但除此之外很少见。他们需要系统管理员访问权限吗？等等。

例如（取自配置 Windows 服务帐户和权限 …