SharePoint 2007 - RunWithElevatedPrivileges - 使用此漏洞的陷阱

Question

我有一种强烈的直觉，即应该像瘟疫一样避免使用SharePoint RunWithElevatedPrivileges，但需要让其他人相信其确切原因。这就是我所拥有的。

• 使用提升的权限生成新线程
• 阻止其他操作，直到传递的委托返回
• 安全问题（可能由最终用户以高级别权限运行）
• 其他？

Answer 1

将跌倒分为两类的原因：

1. 您的代码需要在SharePoint中执行当前用户没有权限的操作。这应始终在使用使用 SharePoint安全性时完成，而不是“以防万一”，这表明您需要更好地了解您的安全状况。
2. 您的代码需要访问应用程序池标识可以访问但当前用户没有访问的外部资源（服务器文件系统，数据库，文件共享等）。

对于前者，使用SPSite impersonation会更好。后者是我使用RWEP的唯一原因。

为了澄清，RWEP不会产生新的线程。相反，它使用Win32 API将当前线程的标识恢复为进程标识（关闭模拟）以运行提升的代码，然后重新开启模拟以代表当前用户恢复工作。这有几个含义：

1. 如果线程未被模拟，则RWEP不执行任何操作，因此在计时器作业，Visual Studio工作流，控制台应用程序以及通过stsadm（功能接收器）运行的代码中无用。
2. 假设您在CodeToRunElevated中创建新的SPSite，将使用应用程序池（SHAREPOINT \ system）的权限执行对SharePoint的访问。此帐户将具有对当前Web应用程序的完全访问权限，但不应具有服务器场级权限，以执行修改SPFarm属性或对SSP进行更改等操作。
3. 在CodeToRunElevated的执行边界中使用身份识别对象（如SPSite及其子代）有可能导致一些非常时髦的行为和竞争条件。对于所有意图和目的，请考虑这不受支持。

正如亚历克斯所说，SPSite的子级继承了SPSite的权限，而SPSite在创建时又设置了权限。因此，即使您在CodeToRunElevated中引用它，SPContext.Current.Site仍将使用当前用户的权限。相反，您需要在提升的块中创建和使用新的SPSite。

总结：RWEP模拟SharePoint之外的应用程序池，SPSite模拟模拟SharePoint内部的应用程序池。

Answer 2

1）大量使用RWEP是代码异味的良好指示。它可以很容易地被滥用，而不会导致严重的安全问题。许多开发人员并没有考虑用户可以做什么，他们间接地在“引擎盖下”给予他们权力。

仅举一个例子：在将RWEP用于prevent malicious requests in application pages之前调用ValidateFormDigest非常重要。

---

2）需要在RWEP的上下文中创建SPWeb和SPSite对象。这对新手开发人员来说很容易忘记，导致很多挫折。

此限制还意味着必须在RWEP委托结束之前使用和完成由这些对象创建的所有工作和任何对象。这是另一个常见的错误。

Keith Dahlby编写extension methods来解决这些问题，提供更强大，更易读的代码。

Answer 3

与所有其他事情一样，RWEP也有利有弊。

如果您担心最终用户正在运行RWEP，可能您已经遇到了更大的问题，因为该代码已经安装在GAC上。

有时，您只需要坚持下去：考虑一个没有管理员权限的用户，运行文档工作流程。在此用户批准（或拒绝，无关紧要）之后，您的工作流引擎应该能够重新定义该SPListItem权限。

Answer 4

我使用它，并发现它是非常有用的功能。在我看来，我选择让用户运行我的代码并让代码执行用户通常无法做的事情。您可以锁定某些内容，并且仍然允许用户以非常受控的方式访问它。