数据库威胁模型解析-CSDN博客

我终于有了喘息的机会，可以开始处理我的积压工作。我从一些背景开始，这将使以后发表文章的动机更加清晰。

应用程序持久层的威胁模型是什么，特别是对数据库本身的威胁？请记住，“威胁”是不利的行为，无论是故意的（攻击者）还是偶然的（例如，分心的员工）。我在下文中指的是“攻击者”，但这是为了方便起见-在许多情况下，非恶意员工更有可能犯错。

攻击者可以访问该应用程序

场景：一个偶然的攻击者，可以作为访问者或用户访问Web应用程序。

漏洞：SQL注入。

对策：使用位置参数，而不是直接显式构造SQL语句。即使您使用即席清理或在数据库供应商提供的库中使用清理，也是如此。参数化并非总是可行的，但应仔细审查例外情况。应始终使用此对策。

以应用程序数据库用户身份访问数据库的攻击者

方案：攻击者可以通过SQL注入或其他机制以应用程序数据库用户的身份对数据库进行完全访问。

漏洞：DDL命令–攻击者可以创建，更改或删除表。

对策：应用程序的数据库用户应拥有数据，但另一个数据库用户应拥有架构。这样可以防止受感染的帐户修改表。应始终使用此对策。

漏洞：数据损坏（预防）。

对策：这是一种很少使用的方法，有时用于最敏感的信息。应用程序用户对表具有SELECT权限，但没有INSERT，UPDATE或DELETE权限。第二个对表具有INSERT，UPDATE和DELETE权限的数据库帐户将创建存储过程以更新数据。这些存储过程被配置为在所有者（而不是调用者）的权限下运行。应用程序可以照常读取数据，但是必须使用存储过程对其进行更新。

这并不像听起来那么麻烦，因为读取数据的频率远远高于修改数据的频率，并且读取不受影响。数据插入和修改更为复杂，但在编写良好的应用程序中，它将被持久层完全封装。

一种变体是使用一个数据库用户读取数据（仅具有SELECT权限），而使用第二个数据库用户修改数据（具有INSERT，UPDATE和DELETE权限）。该应用程序自由使用第一个帐户，但仅对第二个帐户使用经过仔细审查的代码。主要缺点是现代持久性框架大量使用了缓存，因此需要注意确保缓存一致。

这种对策通常仅与高价值内容一起使用，例如用户身份验证信息。

漏洞：数据损坏（检测）。

对策：数据库包含影子列，这些影子列在写入时进行更新，并在读取时进行验证。应该以编程方式执行更新-如果通过触发器完成更新，则所有更新似乎都有效。

有几种变体。阴影列可以是：

·简单的副本 –很容易，但是攻击者可以轻易地对其进行欺骗。

·加密哈希 –除非加了盐，否则很难欺骗，但是哈希可以覆盖多列。除非哈希包含行的主键，否则攻击者很容易从现有行中复制值。这应被视为最低可接受的方法。

·加密消息摘要（HMAC） –不可能被欺骗，因为它需要私钥，但像以前一样，它应该合并行的主键，以防止攻击者从现有行中复制值。这种方法在计算上最昂贵，并且需要注意密钥管理，但是它也可以最好地确保内容没有被修改。

阴影列还有三个单独的位置：

·表格本身 –对任何攻击者来说最简单但也很明显。

·在单独的表中 –对攻击者而言不那么明显，但更难以实现。

·在单独的架构中 -不太明显，但需要最大的努力。

漏洞：数据损坏（检测）。

对策：数据库表添加了INSERT，UPDATE和DELETE触发器。调用的功能捕获现有和修改的数据（如果有），时间戳，主键，数据库用户以及其他可能感兴趣的东西。（例如，某些数据库可以提供远程IP地址。）此信息将写入单独的日志表。

这使组织能够重新构造修改值的时间轴。如果攻击者临时更改值，执行未经授权的操作然后恢复原始值以试图掩盖其踪迹，则这尤其重要。

漏洞：未经授权的披露（检测）。

对策：这是另一种很少使用的方法，有时用于获取最敏感的信息。应用程序用户对表没有任何权限。第二个对表具有SELECT权限的数据库帐户将创建存储过程以访问数据。这些存储过程被配置为在所有者（而不是调用者）的权限下运行。应用程序必须使用存储过程来访问数据。

存储过程记录对日志表的部分或全部访问。

此方法可用于标记对高价值数据的访问。这可以是公共人物（例如政客或名人）的任何分类数据，犯罪或财务记录。应用程序可以并且也应该标记此访问权限，但是仅应用程序无法检测到直接的数据库访问权限。

漏洞：未经授权的披露（检测）。

对策：这个想法已经存在了很长时间，但是直到最近才引起人们的注意。该数据库的前哨值在列中具有对地下的价值，这些值对地下有用-信息在身份盗窃，信用卡欺诈等方面有用。这些值永远不会通过应用程序访问，因为它们已链接到不存在的电子邮件地址，但攻击者却没有确定这一点的方法。（很少有攻击者会知道这是可能的。）

然后可以监视地下论坛的这些值的出现。如果出现前哨值，则组织将知道该数据库已被破坏。一种变体是向哨兵提供有限的价值，例如，“被盗的信用卡”可能具有$ 100的信用额度，因此将了解任何使用的详细信息，并且刑事当局将能够证明其实际使用和损失。

在大多数情况下，组织仅会了解已发生妥协的事实，而仅应足以触发行动。

具有完全访问数据库备份权限的攻击者

场景：攻击者拥有对数据库备份的完全访问权限。

漏洞：未经授权的披露。

对策：应该对备份进行整体加密（例如，使用PGP / GPG），或者可以在数据库中对列进行加密。两种方法都会引入密钥管理问题，例如，您可能希望每月轮换PGP / GPG密钥，以在密钥被泄露时限制暴露。

漏洞：如果攻击者能够修改备份并强制从修改后的备份还原数据库，则数据损坏。

对策：应该对备份进行整体加密（例如，使用PGP / GPG），或者可以在数据库中对列进行加密。另外，我们可以在敏感行上添加HMAC检查。和以前一样，所有方法都会引入关键管理问题。

具有完全访问数据库权限的攻击者

场景：攻击者可以以自己选择的数据酶用户的身份完全访问数据库。

漏洞：一切。

对策：仅限于不存在，具体取决于攻击者的复杂程度。

一个值得注意的例外是使用Unix / Linux共享库或Windows DLL的特定于数据库的扩展。在这些情况下，用户定义的函数可以访问数据库范围之外的数据，例如，存储在文件系统中的密钥或在初始化过程中从Web服务检索的（更好）密码，但是除非有某种机制，否则任何数据库用户都不能访问该信息。明确提供。攻击者可以替换用户定义的功能，但替换将失去功能。