对于Web应用程序数据库，从安全角度来看只有，有什么参数与仅适用于sp的解决方案相反，解决方案中应用程序数据库帐户无权表和视图只有sps的exec？存储过程vs无存储过程 - 安全视点
如果有人拦截了应用程序数据库帐户，那么暴露给攻击的表面区域会比表格和视图不暴露时少得多。非sp解决方案提供（或不提供）哪些安全优势？我发现使用非sp解决方案有很多优势，但揭露所有表格让我有点担心。
的问题是主要的数据库供应商一般产品，但具体而言，SQL Server 2008的
从安全角度来看而已，我看不到任何优势，非SP方法将有超过一个SP的方法，因为：
嗯，我猜你真正抓住了问题你自己的核心：如果你不使用存储过程的所有CRUD操作，您必须至少授予所有表上至少一个特定于应用程序的数据库用户帐户的SELECT权限。
如果您希望允许db帐户做更多的工作，那么该帐户可能还需要其他权限，例如可以在某些表上进行UPDATE和DELETE操作。
我不明白非存储的proc方法会如何获得任何安全性好处 - 它确实打开了大门，问题实际上是：您能负担得起吗？您是否可以确保该应用程序特定的数据库帐户足够多，这样不会影响系统的整体安全性？
一个可能的折衷方案可能是使用视图或访问表允许SELECT，但应付一切使用存储的特效（更新，删除，插入） - 半安全，便捷的一半...
因为它往往是 - 这是便利（非sp方法;使用ORM可能）和安全性（所有SProc方法;可能更麻烦但更安全一点）之间的经典折衷。
马克
谢谢。我想过你的部分解决方案 - 选择表格，更新sps。你有没有尝试过这种方法？任何意想不到的事情都会导致问题？ – Steve 2009-07-29 13:02:20
@Steve：不，我从来没有做过这种混合方法。我以前的工作全是SPRO - 安全的，但一个工作反对的痛苦。我目前的一个是所有的直接表访问 - 方便，但不是非常安全.... – 2009-07-29 13:33:11
这是传统的智慧是正确的一个领域：刚刚露出的存储过程为您提供了更安全的控制。直接访问表格和视图比较容易，而且有时候需要这样做，但安全性会降低。
最大的安全优势，以不使用存储过程的透明度。通过查看它具有的表的访问权限，您可以确切知道帐户的功能。有了存储过程，情况并非一定如此。如果一个帐户有能力执行过程X，那么这会限制帐户执行该操作并且不会触击底层表，但X可以执行任何操作。它可以删除表，修改数据，删除数据等。
要知道帐户可以用存储过程做什么，您必须查看存储过程。每次更新存档时，有人必须查看它的作用，以确保某些内容没有被“意外”放入其中。 sprocs安全性的真正问题来自组织内部，而不是来自流氓攻击者。
下面是一个例子：
比方说，你想限制访问的职员表。没有存储过程，你只是拒绝访问表。要访问某人，必须公然要求您授予权限。当然，他们可以让你运行一个脚本来授予访问权限，但是大多数人至少会尝试修改一个改变数据库模式的脚本（假设脚本没有更新一个sproc，我将在下面讨论）。
应用程序可能有数百个存储过程。根据我的经验，他们经常更新，在这里添加一个字段，在那里删除一个字段。对于某人来说，审阅更新过程脚本的数量总是令人望而生畏，并且在大多数组织中，数据库团队开始只是快速查看过程（或者不要全看），然后一起移动它。这就是真正的问题出现的地方。现在，在这个例子中，如果IT员工中的某个人想要允许访问表，那么该人只需要在授予访问权限或执行其他操作的代码行中加入。在完美的世界里，这会被抓住。我们大多数人不在完美的世界工作。
存储过程的真正问题是它们将混淆的级别添加到系统中。混淆会带来复杂性，并且复杂性最终会导致更多的工作来理解管理底层系统。 IT中的大多数人都过度劳累，而事情就会滑落。在这种情况下，您不会尝试攻击系统以获取访问权限，您可以使用系统负责人来获取您想要的内容。米特尼克是对的，在安全方面人们是问题所在。
大多数针对组织的攻击来自内部。任何时候当你在任何系统中引入复杂性时，都会出现漏洞，可能会忽略一些事情。不要相信它，想想你的工作地点。通过关于您要访问系统的人的步骤。很快你就会意识到，你可以让人们在适当的时候忽略事情。成功进入涉及人员的系统的关键是做一些似乎无害的事情，但实际上是颠覆性的。请记住，如果我试图攻击一个系统：我不是你的朋友;我不是你的朋友;我不是你的朋友;我不是你的朋友;我不是你的朋友;我不是你的朋友。我对你的孩子或爱好没有兴趣;我会以任何必要的方式使用你来获得我想要的;我不在乎我是否背叛了你。 “但他是我的朋友，这就是为什么我相信他相信他所做的事是正确的，”在这个事实之后并不安慰。
除了存储过程的传统安全隔离（对过程的EXEC权限，依靠所有权链接进行数据访问），存储过程可以是code signed，从而对任何服务器功能（如链接服务器， server scoped management views，受控访问stored procedures and even data in other databases以外的用户普通访问。在T-SQL批生产的，无论多么花哨，有多少层在代码生成和ORM层
普通的要求是它的背后，根本无法进行签名，因此不能使用最特定的一个和强大可用的访问控制机制。
让我们来看一个需要非常安全的系统，比如说你的公司的会计系统。如果你只使用procs并授予访问权限，那么除了proc所做的任何事情之外，用户都不能做任何事情。这是一个内部控制，旨在确保系统的任何用户都无法获得系统的业务规则。这阻止了人们购买公司，然后批准资金，从而打开了欺诈的大门。这也可以防止组织中的许多人删除账户表中的所有记录，因为他们没有删除权限，除了从proc授予的删除权限，一次只允许一次删除。
现在开发人员为了开发人员必须拥有更多权利，但是如果您想考虑安全性，他们不应该对生产机器拥有更多权利。确实，开发者可以编写一个恶意软件，当它投入使用时会产生不好的结果。尽管这个开发者可能会将相同的代码放入应用程序版本，并且可能会被捕获或者不会，因为他们会恶意更改proc。就我个人而言，我认为proc可能比较容易被捕获，因为它可能会被dbas从代码中分离出来，这可能意味着管理者或配置管理人员，而dbas有机会只看管理者或配置管理人员。我们都知道现实是，没有人推动代码推动自己的每一件事，因此聘请值得信赖的开发人员是至关重要的。让代码审查和源代码控制到位可以帮助发现恶意更改或将其回滚到以前的版本，但sps副应用程序代码的使用无论如何都面临开发人员的风险。
系统管理员也是如此。为了完成工作，该系统必须拥有完整的系统权限。他们可能会造成很大的损失而不被发现。在这种情况下，你可以做的最好的做法是尽可能少的人尽可能地限制这种访问，并尽可能地雇用值得信赖的人。至少如果您拥有这种访问权限的人很少，那么发现问题的来源会更容易。您可以通过非现场备份来最大限度地降低风险（因此，至少如果管理员变坏，可以在一定程度上修复该问题），但是您永远无法完全摆脱此风险。无论您允许应用程序访问数据的方式如何，都是如此。
因此，sps的真正用处并不是消除所有可能的风险，而是为了让更少的人能够伤害系统。使用应用程序代码来影响数据库信息本质上是不安全的，我认为在任何存储财务信息或个人信息的系统中都不应该允许使用这些代码。
这是一个不完美的类比，但我喜欢将数据库的“dbo”模式中的表与OO术语中的“私有”数据进行比较，并将Views和Stored Procs中的数据与“public”进行比较。甚至可以将一个“公共”模式与dbo模式分开以明确区分。如果你遵循这个想法，你将获得安全优势以及可扩展性优势。
一个帐户（不是Web应用程序的帐户）拥有dbo访问权限并拥有该数据库，并且该Web应用程序使用另一个限于面向公共结构的帐户进行连接。
唯一可能的反对意见是，我遇到了某些语句无法在SP中有效参数化的情况（并且需要动态SQL），并且这可以为您提供SP内SQL注入的可能性。但这是一个非常狭窄的考虑因素，这是一个罕见的情况。至少在PostgreSQL中，我曾经偶尔看到过一些需要额外审查的情况。在整体上，即使在这些情况下，我认为SP类型方法在安全性方面给您带来了好处，因为它们意味着应用程序可以使用通用的反SQL注入机制，否则它可能无法实现，而您的SP可以被许多应用程序使用。此外，如果所有活动都必须经过SP，那么您可以减少对SQL注入的暴露，并集中审核问题。
一般来说，用户可以做的事情越少，安全风险就越低。这意味着用户用SQL注入攻击可以做的越少。
存储过程通常会提供更好，更细化的安全性，这比您无法做到的要好。
这里的大多数答案都指出了使用存储过程的安全优势。如果没有忽视这些优势，有没有提到的几大缺点：
的数据访问模式有时比正在做具体程序重要得多。我们希望记录/监控/分析/提高警报/阻止访问数据的人员，何时以及如何。使用存储过程时，我们不能总是获取这些信息。
一些组织可能有大量的存储过程。对它们进行审查是不可能的，并且将注意力集中在表格上可能更有意义（尤其是在考虑存储过程可能非常复杂，存在错误并引入其他安全问题时）。
某些组织可能需要分开关注。数据库管理员（或任何编写存储过程的人员）并不总是安全个人的一部分。有时候安全人员只需要关注数据，因为他们对业务逻辑和编写业务逻辑的人员没有责任，并不完全信任。
+1抽象（“封装/隐藏”） – 2010-01-27 12:51:09