AllowUnsafeUpdates 的最佳模式 [英] Best Pattern for AllowUnsafeUpdates

问题描述

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

So far, in my research I have seen that it is unwise to set AllowUnsafeUpdates on GET request operation to avoid cross site scripting. But, if it is required to allow this, what is the proper way to handle the situation to mitigate any exposure?

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

Here is my best first guess on a reliable pattern if you absolutely need to allow web or site updates on a GET request.

最佳实践?

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

        }
    }

感谢对最佳模式的反馈.

Feedback on the best pattern is appreciated.

推荐答案

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

If you're performing any operations which modify something, then anyone that can convince the user to click on a link can perform that operation. For instance, let's assume that you have a GET request to a page which lets the user add an administrator to a site, and the user clicks a link to a page which does a Response.Redirect("http://yourserver/_layouts/admin.aspx?operation=addAdministrator&username=attackerNameHere").

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

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

While normally a POST does not offer much protection against this (nothing will stop someone from having a <form method="post" action="http://yourserver/_layouts/admin.aspx">), SharePoint has a concept of form digests, which contain information about the previous request that is generating the post back (including the user's name). This reduces the footprint for this kind of attack significantly.

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

The only time that it is not a security issue to AllowUnsafeUpdates on a GET is if you're not taking input from the user. For instance, if you have a web part which also logs visits to a list, then there's no security vulnerability exposed.

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

Edit: If you are going to use AllowUnsafeUpdates, there's no need to reset it to its previous value. It does not get persisted. It's just something you need to set on an SPWeb object before performing updates from a GET (or other cases)

这篇关于AllowUnsafeUpdates 的最佳模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！