Die besten Muster für die von AllowUnsafeUpdates

Bisher in meiner Forschung habe ich gesehen, dass es unklug ist, zu setzen, von AllowUnsafeUpdates auf GET-request-operation zu vermeiden, cross-site-scripting. Aber, wenn es erforderlich ist, um das zu erlauben, was ist der richtige Weg, um mit der situation zu mindern, eine Exposition?

Hier ist meine beste erste Vermutung auf eine zuverlässige Muster, wenn Sie absolut müssen es erlauben, web-oder Website-updates auf einen GET-request.

Best Practice?

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 auf die besten Muster geschätzt wird.

InformationsquelleAutor der Frage webwires | 2008-10-17

7

Wenn Sie eine Aktion auszuführen, die zu ändern, etwas, dass jeder kann den Benutzer dazu verleiten, auf einen link zu klicken kann ausführen dieses Vorgangs. Zum Beispiel, nehmen wir an, Sie haben eine GET-Anforderung an eine Seite, die ermöglicht dem Benutzer das hinzufügen der administrator einer Website, und der Benutzer klickt auf einen link zu einer Seite, die nicht eine Antwort.Redirect("http://yourserver/_layouts/admin.aspx?operation=addAdministrator&username=attackerNameHere").

Während normalerweise ein POST nicht bieten viel Schutz gegen diese (wird nichts stoppen jemand aus mit einer <form method="post" action="http://yourserver/_layouts/admin.aspx">), SharePoint hat ein Konzept der form verdaut werden, enthalten Informationen über die bisherige Anforderung, dass die Erzeugung der post zurück (darunter den Namen des Benutzers). Dies reduziert den Platzbedarf für diese Art von Angriff deutlich.

Das einzige mal, dass es nicht eine Frage der Sicherheit, um von AllowUnsafeUpdates auf eine zu BEKOMMEN ist, wenn Sie nicht die Einnahme von den Eingaben des Benutzers. Zum Beispiel, wenn Sie haben eine web-Teil, der meldet sich auch Besuche in einer Liste, dann gibt es keine Sicherheits-Schwachstelle ausgesetzt.

Bearbeiten: Wenn Sie gehen, um von AllowUnsafeUpdates, es gibt keine Notwendigkeit, um es zurückzusetzen, um den vorherigen Wert. Es nicht erhalten blieb. Es ist nur etwas, das Sie benötigen, um auf ein SPWeb-Objekt vor der Durchführung der updates von einem BEKOMMEN (oder in anderen Fällen)

InformationsquelleAutor der Antwort Yuliy

Ich würde etwas ändern Trent ' s zu delegieren, zu akzeptieren, das web zu aktualisieren:

public static void DoUnsafeUpdate(this SPWeb web, Action<SPWeb> action)
{
    try
    {
        web.AllowUnsafeUpdates = true;
        action(web);
    }
    finally
    {
        web.AllowUnsafeUpdates = false;
    }
}

Und dann verlängern HttpContext zu Kapseln überprüfung der digest-form, mit einer option zu erhöhen mit dem Technik, die hier beschrieben:

public static void DoUnsafeUpdate(this HttpContext context, Action<SPWeb> action, bool elevated)
{
    SPWeb web = SPControl.GetContextWeb(context);
    if (!context.Request.HttpMethod.Equals("POST", StringComparison.Ordinal)
        || web.ValidateFormDigest())
        throw new SPException("Error validating postback digest");

    if (elevated)
        web.RunAsSystem(w => w.DoUnsafeUpdate(action));
    else
        web.DoUnsafeUpdate(action);
}

Verwendung:

protected override void OnLoad(System.EventArgs e)
{
    Context.DoUnsafeUpdate(web =>
    {
        //Update elevated web
    }, true);
}

InformationsquelleAutor der Antwort dahlbyk

Einem anderen, sauberen Weg zu implementieren, wäre die Nutzung einer Kombination von erweiterungsmethoden und anonyme Delegaten als solche:

public static void DoUnsafeUpdate(this SPWeb web, Action action)
{
    bool allowUnsafeUpdates = web.AllowUnsafeUpdates;
    web.AllowUnsafeUpdates = true;
    action();
    web.AllowUnsafeUpdates = allowUnsafeUpdates;
}

Mithilfe der oben genannten extension-Methode, Sie können dann Ihre "unsichere update" - Aktion wie folgt:

var web = SPContext.Current.Web;
web.DoUnsafeUpdate(delegate()
{
    //Put your "unsafe update" code here
});

InformationsquelleAutor der Antwort Trent

Für von AllowUnsafeUpdates, ich verfolge diesen Prozess:

if( HttpContext.Current is null )
{
  Do nothing, no need to set AllowUnsafeUpdates to true nor
  to call ValidateFormDigest() because update will be carried out
}
else //HttpContext.Current is NOT null
{
  if( SPContext.Current is null )
  {
    Need to set AllowUnsafeUpdates to true
  }
  else //SPContext.Current is NOT null
  {
    Call ValidateFormDigest()
  }
}

InformationsquelleAutor der Antwort Ariel

1

Nicht so sicher, es ist daran zu erinnern, den vorherigen Wert von ermöglichen, unsichere updates.

Ich würde mir wünschen, wickeln Sie das nennen, rund um die minimal mögliche Menge an code, so dass verschachtelte Aufrufe es nicht geschehen würde.

Dann können Sie einfach schalten Sie ihn auf " false danach.

InformationsquelleAutor der Antwort Nat

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.