sharepoint - AllowUnsafeUpdates 的最佳模式

Question

到目前为止，在我的研究中，我发现在 GET 请求操作上设置 AllowUnsafeUpdates 以避免跨站点脚本是不明智的。但是，如果需要允许这样做，那么处理这种情况以减轻任何风险的正确方法是什么？

如果您绝对需要在 GET 请求中允许网站或站点更新，这是我对可靠模式的最佳初步猜测。

最佳实践？

protected override void OnLoad(System.EventArgs e)
{
    if(Request.HttpMethod == "POST")
    {
        SPUtility.ValidateFormDigest();
        // will automatically set AllowSafeUpdates to true
    }

    // If not a POST then AllowUnsafeUpdates should be used only
    // at the point of update and reset immediately after finished

    // NOTE: Is this true? How is cross-site scripting used on GET
    // and what mitigates the vulnerability?
}

// Point of item update

    using(SPSite site = new SPSite(SPContext.Current.Site.Url, SPContext.Current.Site.SystemAccount.UserToken))
    {
        using (SPWeb web = site.RootWeb)
        {
            bool allowUpdates = web.AllowUnsafeUpdates; //store original value
            web.AllowUnsafeUpdates = true;

            //... Do something and call Update() ...

            web.AllowUnsafeUpdates = allowUpdates; //restore original value

        }
    }

对最佳模式的反馈表示赞赏。

Answer 1

如果您正在执行任何修改某些内容的操作，那么任何可以说服用户单击链接的人都可以执行该操作。例如，假设您有一个对页面的 GET 请求，该请求允许用户向站点添加管理员，并且用户单击指向执行 Response.Redirect("http://yourserver/_layouts/admin.aspx?operation=addAdministrator&username=attackerNameHere ") 的页面的链接。

虽然通常 POST 不会对此提供太多保护(没有什么可以阻止某人拥有

)，但 SharePoint 有一个表单概念摘要，其中包含有关生成回发的先前请求的信息(包括用户名)。这显着减少了这种攻击的足迹。

GET 上的 AllowUnsafeUpdates 不是安全问题的唯一情况是您没有接受用户的输入。例如，如果您有一个 Web 部件也记录对列表的访问，那么就没有暴露的安全漏洞。

编辑 :如果您打算使用 AllowUnsafeUpdates，则无需将其重置为以前的值。它不会持久化。这只是您需要在从 GET(或其他情况)执行更新之前在 SPWeb 对象上设置的内容