Freigeben über

Bewährte Methoden für Entwickler zur SharePoint 2010-Sicherheit

  • Artikel

Zusammenfassung:  Empfehlungen zu bewährten Methoden für die Sicherheit bei der Entwicklung mit Microsoft SharePoint 2010.

Letzte Änderung: Montag, 9. März 2015

Gilt für: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Inhalt dieses Artikels
Einführung in bewährte Methoden für die SharePoint-Sicherheit
Bewährte Methoden für die SharePoint-Sicherheit: Siteübergreifendes Skripting
Bewährte Methoden für die SharePoint-Sicherheit: Cross-Site Request Forgery
Bewährte Methoden für die SharePoint-Sicherheit: Rechteerweiterungen
Bewährte Methoden für die SharePoint-Sicherheit: Denial of Service
Bewährte Methoden für die SharePoint-Sicherheit: Veröffentlichung von Informationen
Schlussbemerkung
Weitere Ressourcen

Bereitgestellt von:  Matt Swann, Microsoft Corporation

Inhalt

  • Einführung in bewährte Methoden für die SharePoint-Sicherheit

  • Bewährte Methoden für die SharePoint-Sicherheit: Siteübergreifendes Skripting

  • Bewährte Methoden für die SharePoint-Sicherheit: Cross-Site Request Forgery

  • Bewährte Methoden für die SharePoint-Sicherheit: Rechteerweiterungen

  • Bewährte Methoden für die SharePoint-Sicherheit: Denial of Service

  • Bewährte Methoden für die SharePoint-Sicherheit: Veröffentlichung von Informationen

  • Schlussbemerkung

  • Weitere Ressourcen

Einführung in bewährte Methoden für die SharePoint-Sicherheit

Dieser Artikel enthält Empfehlungen zu bewährten Methoden für die Sicherheit, die Sie bei der Entwicklung mit Microsoft SharePoint 2010 berücksichtigen sollten. Die Liste umfasst Aspekte von siteübergreifendem Skripting (Cross-Site Scripting, XSS), Cross-Site Request Forgery (siteübergreifende Aufrufmanipulation, CSRF oder XSRF), Rechteerweiterungen, Denial of Service und der Veröffentlichung von Informationen.

Bewährte Methoden für die SharePoint-Sicherheit: Siteübergreifendes Skripting

Bei Angriffen mit siteübergreifendem Skripting (Cross-Site Scripting, XSS) werden Sicherheitslücken bei der Webseitenvalidierung ausgenutzt, indem clientseitiger Skriptcode eingeschleust wird. Häufige Sicherheitslücken, die Webanwendungen für Angriffe durch siteübergreifendes Skripting anfällig machen, sind Fehler bei der Validierung von Eingaben oder bei der Codierung von Ausgaben sowie Vertrauen gegenüber Daten, die aus einer freigegebenen Datenbank abgerufen wurden.

In den folgenden Abschnitten werden diese Sicherheitslücken beschrieben und Empfehlungen angegeben. Weitere Informationen zu XSS finden Sie unter Gewusst wie: Verhindern von siteübergreifendem Skripting in ASP.NET.

Richtiges Codieren von Ausgaben mit SPHttpUtility-Methoden

Angreifer möchten ECMAScript (JavaScript, JScript) auf Ihrer Website ausführen, um Authentifizierungscookies zu stehlen und Administratoren zur Ausführung schädlicher Aktionen zu verleiten.

Diese Angreifer suchen nach Stellen mit fehlerhaft codierten Benutzereingaben, an denen die Benutzereingabe als HTML oder JavaScript interpretiert werden kann. Beispielsweise würde ein mit <script>alert()</script> gekennzeichnetes Listenelement JavaScript ausführen, wenn es nicht mithilfe von Microsoft.SharePoint.Utilities.SPHttpUtility.HtmlEncode HTML-codiert wird, bevor es auf dem Client gerendert wird.

Empfehlung

Codieren Sie Benutzerdaten vor dem Rendern auf dem Client mithilfe der entsprechenden Methode aus der SPHttpUtility-Klasse. Quellen von Benutzerdaten sind unter anderem:

  • Daten aus dem SharePoint-Objektmodell (z. B. Feldwerte und Listentitel)

  • Parameter aus der Abfragezeichenfolge, Header, Cookies oder Formulartext in der Anforderung

  • Webdienstparameter

Die zu verwendende Codiermethode hängt von der Verwendung der Daten auf dem Client ab, wie in Tabelle 1 gezeigt.

Tabelle 1. Zur Codierung zu verwendende SPHttpUtility-Methode

Typ

Zu verwendende "Microsoft.SharePoint.Utilities.SPHttpUtility"-Klassenmethode

Innerer Text eines HTML-Tags

HtmlEncode

Innerer Text eines HTML-Tags, Basisformatierung zulässig

HtmlEncodeAllowSimpleTextFormatting

Attribut eines HTML-Tags, keine URL

HtmlEncode

Attribut eines HTML-Tags, URL

HtmlUrlAttributeEncode

JavaScript

EcmaScriptStringLiteralEncode

Bekannte sichere Werte (z. B. GUID aus einem Abfrageparameter)

NoEncode

Durch einen Aufruf von SPHttpUtility.NoEncode können Sie den Quellcode auf Codierprobleme überwachen. Durch den Aufruf von SPHttpUtility.NoEncode zeigen Sie, dass Sie darüber nachgedacht haben, ob dieser Wert codiert werden muss.

Können Sie stattdessen die HttpUtility-Encoder von Microsoft .NET Framework verwenden?

Nein, dies wird nicht empfohlen. Mit der HttpUtility-Encoderbibliothek von .NET Framework werden nicht alle Zeichen ausreichend codiert. Beispielsweise wird ein einfaches Anführungszeichen von SPHttpUtility in SharePoint als &#39; codiert, während HttpUtility von .NET Framework das einfache Anführungszeichen nicht codiert. Dies würde zu einem XSS-Fehler führen, wie im folgenden Code dargestellt.

Response.Write("<a href='http://contoso/" + 
HttpUtility.HtmlAttributeEncode(Request.QueryString["target"]) + 
"'>test</a>");

Verhindern, dass mitwirkende Benutzer der Website Skripts hinzufügen

Einige Features in SharePoint 2010 ermöglichen Benutzern die Erstellung von JavaScript auf der Website. Beispiel:

  • Mit dem Inhalts-Editor-Webpart kann einer Seite beliebiger JavaScript-Code hinzugefügt werden.

  • Einige Dokumenttypen werden beim Herunterladen im Browser als HTML gerendert, wodurch Skripts ausgeführt werden können.

Benutzer ohne die Berechtigung Seiten hinzufügen und anpassen werden als nicht vertrauenswürdig eingestuft. Diese dürfen der Website mit den Features, die Benutzern das Hinzufügen von Skripts zur Website ermöglichen, keine Skripts hinzufügen. Benutzer mit der Berechtigungsstufe Mitwirken verfügen nicht über dieses Recht.

HinweisHinweis

Weitere Informationen zu Berechtigungen in SharePoint 2010 finden Sie unter Kapitel 11: Benutzer und Berechtigungen.

Empfehlung

Wenn Ihr Feature Benutzern das Hinzufügen von Skript zur Website ermöglicht, müssen von dem Feature die Berechtigungen des aktuellen Benutzers überprüft und Benutzer ohne die Berechtigung SPBasePermissions.AddAndCustomizePages gesperrt werden. Im folgenden Code ist dies dargestellt.

if (!SPContext.Current.Web.DoesUserHavePermissions(SPBasePermissions.AddAndCustomizePages))
{
   // User does not have permission to add script to the site. 
   // Either disable the feature or throw an access denied exception.
   throw new UnauthorizedAccessException();
}

Wenn in einem Feature von Benutzern hochgeladene Dokumente angezeigt oder heruntergeladen werden, muss von dem Feature bei der Rückgabe des Dokuments der HTTP-Antwortheader X-Content-Type-Options: nosniff angefügt werden. Muss das Dokument nicht im Browser gerendert werden, müssen Sie zwei zusätzliche HTTP-Antwortheader senden, um dies zu verhindern. Die folgenden HTTP-Antwortheader müssen gesendet werden:

  • X-Download-Options: noopen

  • Content-Disposition: attachment

Festlegen eines Zeichensatzes im HTTP-Antwortheader "Content-Type"

Häufig möchten Entwickler XSS-Angriffen vorbeugen, indem sie Eingaben mit Sonderzeichen wie spitzen Klammern (< und >) blockieren. Leider müssen Angreifer keine spitzen Klammern verwenden, um ein <script>-Tag einzuschleusen, wenn sie den Browser dazu bringen können, die Seite als UTF-7 oder einen anderen Zeichensatz zu interpretieren.

Empfehlung

Geben Sie immer einen Zeichensatz im HTTP-Antwortheader Content-Type an. In der Regel sollte dies das UTF-8-Format sein, wie im folgenden Beispiel dargestellt.

Content-Type: text/html; charset=UTF-8

Diese Angabe des Zeichensatzes verhindert, dass Angreifer den Zeichensatz des Browsers vom Inhalt der Seite aus steuern.

Zusätzlich zum Zeichensatz empfiehlt sich die Angabe des nosniff-Headers, um MIME-Ermittlung zu verhindern.

Keine vom Benutzer bereitgestellten Werte in Format- und Ereignisattributen zulassen

Obwohl es nicht ratsam ist, vom Benutzer bereitgestellte Werte in Format- und Ereignisattributen zuzulassen, kommt dies doch gelegentlich vor. Es wird empfohlen, folgendermaßen mit vom Benutzer bereitgestellten Daten zu verfahren.

Empfehlung

Verwenden Sie keine vom Benutzer bereitgestellten Werte in Formatattributen. Auch die Verwendung von HTML-Codierung bietet keinen Schutz. Die Problembehebung bei Verwendung von HTML-Codierung ist von Fall zu Fall unterschiedlich, wie die folgenden Beispiele zeigen.

Beispiel 1: Der folgende gesamte Formatattributwert ist codiert, lässt jedoch weiterhin die Ausführung von Skript zu, da alle Browser Attributwerte vor der Verwendung aus HTML decodieren. In diesem Fall nützt eine HTML-Codierung nichts, und es gibt keine brauchbare Möglichkeit, diese Sicherheitslücke zu schließen.

<html>
  <body>
     <div style="&#119;&#58;&#101;&#120;&#112;&#114;&#101;&#115;&#115;&#105;&#111;&#110;&#40;&#97;&#108;&#101;&#114;&#116;&#40;&#41;&#41;"></div>
  </body>
</html>

Beispiel 2: Für font-family sollen möglicherweise nur Schriftarten zugelassen werden, die als sicher bekannt sind. Für background-image müssen Sie möglicherweise den verwendeten Protokollhandler überprüfen. Außerdem muss die URL überprüft werden, um sicherzustellen, dass kein neues Formattoken eingeschleust wurde.

Verwenden Sie keine vom Benutzer bereitgestellten Werte in Ereignisattributen. Auch hier bietet die Verwendung von HTML-Codierung keinen Schutz. Die Problembehebung bei Verwendung von HTML-Codierung ist von Fall zu Fall unterschiedlich.

Stattdessen sollten Sie JavaScript-Codierung verwenden und in manchen Fällen die vom Benutzer bereitgestellten Daten zweimal codieren. Nachstehend sind einige Beispiele aufgeführt.

Beispiel 1: Für den folgenden Code ist JavaScript-Codierung ausreichend.

<a href="#" onclick="alert(__USER_PROVIDED_DATA__)">

Beispiel 2: Für den folgenden Code sollten die Daten zunächst in HTML und dann in JavaScript codiert werden.

<a href="#" onclick="document.write(__USER_PROVIDED_DATA_)">

Beispiel 3: Der folgende Code stellt eine inhärente Sicherheitslücke dar. Es gibt keine brauchbare Möglichkeit, dies zu beheben.

<a href="#" onclick="__USER_PROVIDE_DATA__">

Bewährte Methoden für die SharePoint-Sicherheit: Cross-Site Request Forgery

Cross-Site Request Forgery (siteübergreifende Aufrufmanipulation, CSRF oder XSRF) ist ein Angriff, bei dem der Browser des Opfers zu einer unerwünschten Aktion im Auftrag des Opfers veranlasst wird. Derartige Angriffe könnten beispielsweise die Überweisung von Geldbeträgen, die Änderung eines Kennworts oder den Kauf eines Artikels bewirken.

Weitere Informationen zu CSRF finden Sie unter Erläuterungen zum Cross-Site Request Forgery-Angriff.

Überprüfen des Formulardigestcanarys vor der Verarbeitung eines Postbacks

Ein Angreifer kann Beiträge auf Seiten in SharePoint bereitstellen, auch wenn er kein Skript in der Domäne ausführen kann. Wenn Sie zu einer Seite navigieren, deren Besitzer der Angreifer ist, kann er Vorgänge in SharePoint mit Ihren Anmeldeinformationen ausführen.

Der Angreifer kann beispielsweise eine Seite unter http://contoso123 kontrollieren. Wenn Sie zu dieser Seite navigieren, wird mit Ihren Anmeldeinformationen auf http://wingtip/_layouts/deleteweb.aspx gepostet. Sofern Sie über Administratorberechtigungen für http://wingtip verfügen, wird daraufhin die Website http://wingtip gelöscht.

Empfehlung

In SharePoint wird über ein dynamisches Canary sichergestellt, dass POST-Anforderungen aus derselben Domäne stammen wie der Server.

Sie müssen zwei Dinge tun:

  • Senden Sie das Canary mit jedem Postback und jeder Webdienstanforderung mit.

  • Überprüfen Sie das Canary, bevor Sie auf das Postback oder die Webdienstanforderung reagieren.

Die folgenden Schritte sind auszuführen.

  1. Senden Sie das Canary mit jedem Postback und jeder Webdienstanforderung mit.

    Der Canarywert ist bereits in einem ausgeblendeten __REQUESTDIGEST-Formularelement auf jeder Seite vorhanden, welche die SharePoint-Gestaltungsvorlage verwendet. Er wird automatisch mit jedem Postback gesendet.

    Falls die Seite nicht von der SharePoint-Gestaltungsvorlage erbt, müssen Sie den Wert mit dem Microsoft.SharePoint.WebControls.FormDigest-Steuerelement auf die Seite schreiben. Wenn Sie einen Webdienstaufruf ausführen, müssen Sie den __REQUESTDIGEST-Wert abrufen und wie im folgenden Beispiel in den HTTP-Anforderungsheader X-RequestDigest einschließen.

    var canaryValue = document.getElementById('__REQUESTDIGEST').value;
request.SetRequestHeader("X-RequestDigest", canaryValue);

    In Clientanwendungen (außerhalb des Browsers) muss der Canarywert manuell durch einen Aufruf der GetUpdatedFormDigestInformation-Webmethode für den SOAP-Webdienst Sites.asmx abgerufen werden. Dieser Wert muss in den X-RequestDigest-Header jedes Webdienstaufrufs eingeschlossen werden.

    HinweisHinweis

    Der Canarywert läuft nach 30 Minuten ab (konfigurierbar, zurückgegeben von GetUpdatedFormDigestInformation). Somit müssen Clientanwendungen darauf vorbereitet sein, erneut ein gültiges Canary anzufordern, wenn der Server es als zu alt zurückweist. Im Browser ist dies kein Problem – im FormDigest-Steuerelement wird der __REQUESTDIGEST-Formularwert mithilfe von JavaScript entsprechend erneuert.

  2. Überprüfen Sie das Canary, bevor Sie auf das Postback oder die Webdienstanforderung reagieren.

    Bevor Sie auf ein Postback oder einen Webdienstaufruf hin irgendeine Aktion ausführen, müssen Sie durch einen Aufruf von ValidateFormDigest() die Gültigkeit des Canarys überprüfen. Wenn das Canary ungültig ist, wird eine Ausnahme ausgelöst.

    HinweisHinweis

    Dies gilt auch für nicht zustandsverändernde Postbacks, z. B. das Aktualisieren einer Seite mit vom Benutzer gesendetem Inhalt.

Vermeiden der Verwendung von "AllowUnsafeUpdates"

In SharePoint 2010 werden Entwickler daran gehindert, zustandsverändernde Vorgänge für eine GET-Anforderung auszuführen. Beispielsweise kann auf einer Microsoft ASP.NET-Seite der Inhalt eines Listenelements oder einer Webeigenschaft nicht aktualisiert werden, wenn das Listenelement oder die Webeigenschaft mithilfe von GET abgerufen wird.

Zusammen mit dem __REQUESTDIGEST-Canary werden dadurch CSRF-Angriffe verhindert. Einige Features können jedoch eine verzögerte Initialisierung erfordern.

Empfehlung

Wenn Ihr Feature einen zustandsverändernden Vorgang für eine GET-Anforderung ausführen muss, sollten Sie zunächst überprüfen, ob sich das Feature richtig verhält. Es ist ratsam, zustandsverändernde Vorgänge nur für eine POST-Anforderung auszuführen, da Ihr Feature durch das __REQUESTDIGEST-Canary vor CSRF-Angriffen geschützt wird.

Wenn der Entwurf Ihres Features einen zustandsverändernden Vorgang für eine GET-Anforderung bedingt, können Sie diese Überprüfung deaktivieren, indem Sie die AllowUnsafeUpdates-Eigenschaft der aktuellen Microsoft.SharePoint.SPWeb-Klasse auf true festlegen. Denken Sie daran, die Eigenschaft nach dem Vorgang zurückzusetzen, und stellen Sie wie im folgenden Beispiel durch einen try-catch-finally-Block sicher, dass sie nach einer Ausnahme nicht auf true festgelegt bleibt.

try
{
   SPContext.Current.Web.AllowUnsafeUpdates = true;
   // State-changing operation occurs here.
}
catch
{
   // Handle or re-throw an exception.
}
finally
{
   SPContext.Current.Web.AllowUnsafeUpdates = false;
}

AllowUnsafeUpdates darf nie zur Umgehung eines Canaryüberprüfungsfehlers verwendet werden. Wenn bei einem Postback oder einer Webdienstanforderung ein Canaryüberprüfungsfehler auftritt, sollten Sie das Canary ordnungsgemäß senden und überprüfen.

Verwenden von "SPUtility" zur Umleitung auf eine andere Seite

In Formularen wird häufig auf eine andere Seite umgeleitet, nachdem der Benutzer auf OK oder Abbrechen geklickt hat. Die URL dieser Seite wird häufig in einem Abfrageparameter übergeben (z. B. einem Source-Parameter). Wird diese URL nicht überprüft, können Angreifer den Benutzer mithilfe des Parameters an einen möglicherweise schädlichen Ort umleiten.

Empfehlung

Rufen Sie die Microsoft.SharePoint.Utilities.SPUtility.Redirect-Methode auf, um den Benutzer auf eine andere Seite umzuleiten. Die Redirect-Methode stellt sicher, dass sich die Ziel-URL in der aktuellen Domäne befindet. Optional kann sie auch sicherstellen, dass die Umleitung auf eine andere Seite in _layouts auf der aktuellen Webseite erfolgt.

Bewährte Methoden für die SharePoint-Sicherheit: Rechteerweiterungen

Rechteerweiterungen entstehen dadurch, dass einem Angreifer Autorisierungsberechtigungen über die ursprünglich erteilten hinaus zugewiesen werden. Beispielsweise erweitert ein Angreifer, dessen Berechtigungssatz nur Leseberechtigungen umfasst, diesen Satz auf Lese-/Schreibberechtigungen.

Weitere Informationen finden Sie unter Ausweitung von Berechtigungen.

Geeignetes Überprüfen von Benutzerberechtigungen

Unter Umständen werden von einem Feature Berechtigungen nicht automatisch überprüft. Beispiel:

  • Microsoft.SharePoint.SPSecurity.Elevated RunWithElevatedPrivileges-Vorgänge verlaufen unabhängig von den Berechtigungen des Benutzers immer erfolgreich.

  • Bei einigen Vorgängen wird möglicherweise keine Berechtigungsüberprüfung ausgeführt, wenn nicht das SharePoint-Objektmodell verwendet wird.

In diesen beiden Fällen müssen Berechtigungen in dem Feature manuell überprüft werden.

Empfehlung

Bestimmen Sie zunächst, für welches Microsoft.SharePoint.SecurableObject – ein SPListItem-Objekt, ein SPList-Objekt oder ein SPWeb-Objekt – Berechtigungen überprüft werden sollen. Falls das Feature Auswirkungen auf das Web hat, stellt das aktuelle Kontextweb das sicherungsfähige Objekt dar. Arbeitet das Feature listenspezifisch, ist die aktuelle Kontextliste das sicherungsfähige Objekt.

Bestimmen Sie anschließend, ob von dem Feature eine besondere Aktion ausgeführt werden muss, wenn der Benutzer nicht über Berechtigungen verfügt (z. B. Ausblenden einiger Benutzeroberflächenelemente), oder ob der Zugriff verweigert werden sollte.

  • Falls von dem Feature abhängig von den Berechtigungen des Benutzers Aktionen auszuführen sind, rufen Sie DoesUserHavePermissions für das sicherungsfähige Objekt auf, und verwenden Sie den Rückgabewert.

    HinweisHinweis

    Die DoesUserHavePermissions-Methode löst keine Ausnahme aus, wenn der Benutzer nicht über die erforderlichen Berechtigungen verfügt. Es wird lediglich false zurückgegeben.

  • Soll das Feature eine Ausnahme wegen verweigerten Zugriffs auslösen, rufen Sie Microsoft.SharePoint.SPSecurableObject.CheckPermissions für das sicherungsfähige Objekt auf. Dadurch wird eine Ausnahme wegen verweigerten Zugriffs ausgelöst, und die entsprechenden Informationen werden an den Benutzer zurückgegeben.

Sicheres Erstellen der SPSite-Objekte

Mit dem Microsoft.SharePoint.SPSite-Konstruktor können die folgenden beiden Probleme auftreten:

  • Neue SPSite-Objekte können mit dem vollqualifizierten Domänennamen erstellt werden, z. B. http://contoso1.example.com. Unterscheidet sich dieser Domänenname vom aktuellen Anforderungskontext, kann dies zu einem domänenübergreifenden Sicherheitsproblem führen.

  • Neue SPSite-Objekte können mit einer Website-ID und optional einem Benutzertoken, aber ohne vollqualifizierte URL oder Microsoft.SharePoint.Administration.SPUrlZone-Enumeration erstellt werden. Wenn es sich beim aktuellen Anforderungskontext nicht um die Default-Zone handelt, kann dadurch die Webanwendungsrichtlinie umgangen werden.

Empfehlung

Erstellen Sie kein SPSite-Objekt nur mithilfe der Website-ID und des Benutzertokens. Übergeben Sie stattdessen den Microsoft.SharePoint.Administration.SPUrlZone-Enumeratorwert oder den vollqualifizierten Domänennamen der Website.

Wenn Sie ein neues SPSite-Objekt mithilfe eines vom Benutzer bereitgestellten GUID-Werts oder vollqualifizierten Domänennamens erstellen, müssen Sie Microsoft.SharePoint.SPSite.ValidateDomainCompatibility aufrufen. Dadurch wird sichergestellt, dass der Domänenname des neuen SPSite-Objekts mit dem Domänennamen des aktuellen Anforderungskontexts übereinstimmt, wie im folgenden Beispiel gezeigt wird.

String siteUrl = Page.Request.QueryString["site"]; 
// This can be a fully qualified domain names (FQDN), for example,
// http://contoso/sites/example.
 
if (!SPSite.ValidateDomainCompatibility(SPContext.Current.Site.Url, siteUrl))
{
   // If the domain of siteUrl differs from the current context, block cross-domain operations.
   throw new UnauthorizedAccessException();
}

Weitere Informationen zum sicheren Erstellen von SPSite-Objekten

In einem Skript in einer Domäne (beispielsweise https://contoso.com) darf nicht auf Daten in anderen Domänen (beispielsweise http://wingtip.com) zugegriffen werden. Dies wird als Same-Origin Policy bezeichnet.

Das SharePoint-Objektmodell kann jedoch auf beide Domänen zugreifen, wenn sie sich in derselben Farm befinden. Angreifer können dies für Zugriffe auf Daten in einer anderen Domäne ausnutzen, wenn Sie dies nicht mithilfe von Microsoft.SharePoint.SPSite.ValidateDomainCompatibility blockieren.

Getrennt davon können Farmadministratoren die Webanwendungsrichtlinie verwenden, um Benutzern unterschiedliche Rechte für verschiedene Zonen einer Website zu erteilen. Beispielsweise kann Benutzern durch eine Richtlinie Full Control für die Standardzone einer Website, aber nur Read-Zugriff für die Internetzone gewährt werden.

Wenn die Zoneninformationen nicht mithilfe eines Microsoft.SharePoint.Administration.SPUrlZone-Enumeratorwerts oder eines FQDN an den SPSite-Konstruktor übergeben werden, wird vom Objektmodell davon ausgegangen, dass die Standardzone gemeint ist. Dies kann im weiter oben beschriebenen Szenario zu Rechteerweiterungsproblemen führen.

Sorgfältiges Einschränken von serverseitigen HTTP-Anforderungen

Einige Features können den Server veranlassen, ausgehende HTTP-Anforderungen im Auftrag des Benutzers zu senden. Beispielsweise können Benutzer in Microsoft Business Connectivity Services (BCS) Datenbank- und Webdienst-URLs angeben, mit denen eine Verbindung hergestellt werden soll.

Da diese Anforderungen vom Server mit SharePoint stammen, der sich hinter der Firewall befindet, können mit diesen Anforderungen Verbindungen mit anderen Computern im Rechenzentrum hergestellt oder Angriffe auf diese ausgeführt werden.

Empfehlung

Lassen Sie nicht zu, dass Benutzer beliebige URLs für SharePoint-Verbindungen angeben. Ermöglichen Sie stattdessen Farmadministratoren, ein Liste sicherer URLs zu konfigurieren.

Alternativ können Sie jede vom Benutzer eingegebene URL in ihre kanonische IP-Adresse (Internetprotokoll) auflösen und Farmadministratoren die Möglichkeit geben, Netzwerkbereiche nach IP und Subnetzmaske zu blockieren (beispielsweise 192.168.0.0/255.255.0.0).

Objekte mit erhöhten Rechten müssen in einem RunWithElevatedPrivileges-Block bleiben

Mit Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges wird ein Codeblock mithilfe von Anmeldeinformationen für ein Dienstkonto ausgeführt. Dies wird häufig verwendet, um eine Aktion im Auftrag eines Benutzers auszuführen, wenn dieser nicht zur direkten Ausführung der Aktion berechtigt ist.

Beispielsweise hat ein Benutzer möglicherweise nicht die Berechtigung zum Bereitstellen neuer Websitesammlungen, SharePoint muss jedoch eine Website für den Benutzer bereitstellen. Durch Bereitstellen der Websitesammlung in einem RunWithElevatedPrivileges-Block kann die Aktion erfolgreich ausgeführt werden.

Im Allgemeinen wird RunWithElevatedPrivileges folgendermaßen verwendet.

SPSecurity.RunWithElevatedPrivileges(delegate()
{
   using (SPSite elevatedSite = new SPSite(SPContext.Current.Site.Id))
   {
      using (SPWeb elevatedWeb = elevatedSite.OpenWeb(SPContext.Current.Web.Id))
      {
         // Perform administrative actions by using the elevated site and web objects.
      }
   }
});

SharePoint-Objektmodellobjekte, die mithilfe der Objekte mit erhöhten Rechten Microsoft.SharePoint.SPSite und Microsoft.SharePoint.SPWeb erstellt wurden oder auf die über diese Objekte zugegriffen wird, behalten die Berechtigungen, mit denen sie erstellt wurden. Wenn diese Objekte außerhalb des RunWithElevatedPrivileges-Blocks zurückgegeben werden, kann dies zu Rechteerweiterungsproblemen führen.

Empfehlung

SharePoint-Objektmodellobjekte, die in einem Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges-Objekt erstellt wurden oder auf die in einem solchen Objekt zugegriffen wird, dürfen nicht außerhalb des RunWithElevatedPrivileges-Blocks zurückgegeben werden.

Zusätzliche Informationen

Wenn Sie ein SPSite-Objekt instanziieren, wird für dieses Objekt von SharePoint ein zugrunde liegendes SPRequest-Objekt in systemeigenem Code erzeugt. Im SPRequest-Objekt wird verzeichnet, welcher Benutzer das Objekt instanziiert hat. SPRequest wird von allen Objekten gemeinsam verwendet, auf die über dieses SPSite-Objekt zugegriffen wird.

HinweisHinweis

Weitere Informationen zum SPRequest-Objekt finden Sie unter Verwerfen von Objekten.

Wenn ein SPSite-Objekt in einem RunWithElevatedPrivileges-Block bereitgestellt wird, wird vom SPRequest-Objekt vermerkt, dass der aktuelle Benutzer das Systemkonto ist. Wird über das SPSite-Objekt auf ein Microsoft.SharePoint.SPListItem-Objekt zugegriffen, verwendet dieses Listenelement dasselbe SPRequest-Objekt – es handelt sich ebenso wie beim SPSite-Objekt um ein "erhöhtes" Objekt.

Wenn das SPListItem-Objekt außerhalb des RunWithElevatedPrivileges-Blocks übergeben wird, behält es das ihm zugrunde liegende SPRequest-Objekt und bleibt weiterhin erhöht. Bei Code, in dem die Ausführung unter den Anmeldeinformationen des aktuellen Benutzers vorausgesetzt wird, treten Rechteerweiterungsprobleme auf, wenn dieses SPListItem-Objekt verwendet wird.

Bewährte Methoden für die SharePoint-Sicherheit: Denial of Service

Denial of Service (Dienstverweigerung) tritt auf, wenn ein System so stark überlastet ist, dass Nachrichten nicht oder nur extrem langsam verarbeitet werden können. Weitere Informationen finden Sie unter Dienstverweigerung.

Beschränken der Anzahl der durch eine einzelne Anforderung ausführbaren Aktionen

Von einigen Features werden Benutzereingaben analysiert und für jedes Element in der Anforderung eine Aktion ausgeführt. Wenn die Anzahl der analysierten Elemente von dem Feature nicht beschränkt wird, kann dies zu einem Denial-of-Service-Angriff führen.

Empfehlung

Legen Sie eine sinnvolle Obergrenze für die Anzahl der Benutzereingaben fest, die von dem Feature für eine Anfrage verarbeitet werden.

Bewährte Methoden für die SharePoint-Sicherheit: Veröffentlichung von Informationen

Durch die Veröffentlichung von Informationen erhält ein Angreifer wertvolle Informationen über ein System. Daher sollten Sie immer genau überlegen, welche Informationen Sie freigeben und ob sie von einem böswilligen Benutzer missbraucht werden können.

Weitere Informationen finden Sie unter Veröffentlichung von Informationen.

Bereinigen von Webdienstausnahmen vor der Rückgabe an Aufrufer

Ein Webdienstaufruf kann eine Ausnahme auslösen, die zu viele Daten über den Server zurückgibt, wie z. B. interne Servernamen oder Dateisystempfade.

Angreifer können diese Informationen nutzen, um Details über die SharePoint-Farm zu erfahren und einen gezielten Angriff zu starten.

Empfehlung

Fangen Sie beim Implementieren einer SOAP-Webmethode alle Ausnahmen ab, und übergeben Sie sie vor der Rückgabe an den Benutzer an SoapServerException.HandleException, wie im folgenden Beispiel dargestellt.

try 
      {
          return new SoapXml.SoapXmlElement(
              m_ListSchemaImpl.GetListAndView(listName, viewName));
      } 
      catch (Exception e) 
      {
          throw SoapServerException.HandleException(e);
 
      }

Schlussbemerkung

In diesem Artikel erhalten Sie Empfehlungen zu bewährten Methoden für die Sicherheit, die Sie bei der Entwicklung von Lösungen mit SharePoint 2010 berücksichtigen sollten. Die Empfehlungen umfassen Aspekte von siteübergreifendem Skripting (Cross-Site Scripting, XSS), Cross-Site Request Forgery (siteübergreifende Aufrufmanipulation, CSRF oder XSRF), Rechteerweiterungen, Denial of Service und der Veröffentlichung von Informationen.

Weitere Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen: