Absichern von Webparts-Seiten

Článek
10/22/2014

Aktualisiert: November 2007

Webparts sind das neue Feature von ASP.NET, mit dem Endbenutzer Webseiten bearbeiten und personalisieren können. Personalisierte Webseiten sind für Benutzer von Webanwendungen sehr hilfreich und leistungsstark. Sie bringen jedoch auch Auswirkungen auf die Sicherheit mit sich, die Entwicklern bekannt sein sollten.

Sicherheitsaspekte von Webparts

Da Webparts ein Feature von ASP.NET sind und es sich bei Webparts-Steuerelementen um erweiterte ASP.NET-Serversteuerelemente handelt, sind Webparts-Seiten für dieselben Risiken wie ASP.NET-Seiten anfällig. Eine Webanwendung mit Seiten, die Webparts-Steuerelemente verwenden, ist eigentlich nur eine spezialisierte ASP.NET-Anwendung, und eine Anwendung, die Webparts verwendet, kann auf jeder Vertrauensebene ausgeführt werden, auf der eine gewöhnliche ASP.NET-Anwendung ausgeführt werden kann. Allgemeine Informationen zur ASP.NET-Websitesicherheit finden Sie unter Sichern von ASP.NET-Websites. Bei Webparts spielen jedoch einige besondere Sicherheitsaspekte eine Rolle, die bei normalen ASP.NET-Seiten nicht berücksichtigt werden müssen. Diese Aspekte werden in den folgenden Abschnitten beschrieben.

Importieren von Steuerelementdaten

Das Webparts-Feature mit den größten Sicherheitsrisiken ist das Feature zum Importieren. Dieses Feature ermöglicht es Benutzern, eine XML-Beschreibungsdatei zu importieren, die Zustands- und Eigenschaftendaten für ein Serversteuerelement enthält (die Assemblydatei des Steuerelements muss bereits auf dem Webserver verfügbar sein). Mit dem Import von Daten für Steuerelemente können Benutzer Daten freigeben und komplexe Steuerelemente einfach konfigurieren. Es besteht jedoch das Risiko, dass böswillige Daten in der Beschreibungsdatei vorhanden sein können. Wenn beispielsweise böswilliger Skriptcode als Wert einer Zeichenfolgeneigenschaft in der Beschreibungsdatei platziert wird, kann das Skript potenziell ausgeführt werden, wenn ein Benutzer die Beschreibungsdatei importiert und einer Webseite das Serversteuerelement hinzufügt, auf das verwiesen wird. Damit das Risiko beim Importieren von Beschreibungsdateien mit böswilligen Daten minimiert wird, sollten Serversteuerelemente, die über Zeichenfolgentyp-Eigenschaften verfügen, Eigenschaftendaten stets codieren. Ein weiteres Risiko besteht im Importieren von Typen über Beschreibungsdateien (siehe Beschreibungsdateien für Webparts-Steuerelemente). Ein böswilliger Benutzer könnte Anforderungen zum Laden vieler Assemblys in die AppDomain senden. Dies würde dazu führen, dass eine übermäßig hohe Speicherkapazität beansprucht wird. Wenn Sie die mit dem Import verbundenen Risiken vermeiden möchten, können Sie das Feature vollständig deaktivieren, indem Sie das Serversteuerelement nicht verwenden, von dem das Feature implementiert wird. Sie können auch einschränken, welche Benutzer Zugriff auf das Steuerelement haben. Beispielsweise können Sie die Rollenverwaltung verwenden, und wenn ein Benutzer über die Administratorrolle verfügt, können Sie der Seite für diesen Benutzer ImportCatalogPart programmgesteuert hinzufügen. Weitere Informationen zum Steuerelement finden Sie im Referenzthema für die ImportCatalogPart-Klasse.

Exportieren von Steuerelementdaten

Das Feature zum Exportieren birgt nahezu dasselbe Risikopotenzial wie der Import, da damit vertrauliche Daten verfügbar gemacht werden können. Der Export ermöglicht es Benutzern, die Eigenschaften- und Zustandsdaten für ein bestimmtes Steuerelement in einer XML-Beschreibungsdatei zu speichern. (Dies ist dieselbe Datei, die mit dem Importfeature importiert werden kann.) Das größte Risiko besteht hier darin, dass Benutzer möglicherweise vertrauliche Daten aus der Anwendung in die Beschreibungsdatei exportieren. Dies ist eine einfache Textdatei, die von jeder Person mit den entsprechenden Berechtigungen gelesen werden kann. In ASP.NET ist der Export standardmäßig deaktiviert. Wenn Sie das Feature nicht benötigen, können Sie es demnach ignorieren. Dies ist mit Abstand die sicherste Option.

Wenn Sie das Exportieren aktivieren möchten, sollten Sie die Optionen berücksichtigen, mit denen bestimmt wird, welche Eigenschaften exportiert werden können. Wenn Sie einen WebPart oder ein Serversteuerelement erstellen, das in einer WebPartZone-Zone verwendet wird, können Sie für jede öffentliche Eigenschaft, die exportierbar werden soll, das Personalizable-Metadatenattribut hinzufügen. Damit kann die Eigenschaft exportiert werden, wenn der Export aktiviert wurde, und es wird zudem ein Meldungsfeld für den Benutzer angezeigt, das mit einer Warnung darauf hinweist, dass die Daten exportiert werden. Einer der Parameter des Personalizable-Attributs lautet IsSensitive. Dieser boolesche Parameter kann dann eingesetzt werden, wenn eine Eigenschaft in bestimmten Situationen exportierbar sein soll, in anderen jedoch nicht. Ausführliche Informationen sowie ein Beispiel finden Sie im Referenzthema für die ExportMode-Eigenschaft.

Allgemeine Informationen zu Personalisierungsdetails

Die Webparts-Personalisierung ist das Feature, mit dem Webseiten von Benutzern angepasst und ihre Einstellungen im Langzeitspeicher gespeichert werden können. So behalten die personalisierten Seiten die Einstellungen über mehrere Browsersitzungen hinweg bei. Für die meisten Webparts-Features ist die Personalisierung erforderlich. Daher ist sie in der Standardeinstellung auf ASP.NET-Websites aktiviert, obwohl sie nur auf Seiten verwendet wird, die Webparts-Steuerelemente enthalten. Da es sich bei der Personalisierung um solch ein leistungsstarkes Feature handelt, birgt sie auch ein gewisses Risiko. Die Benutzer können das tatsächliche Layout, die Darstellung und selbst den Inhalt sowie die Steuerelemente auf einer Webseite ändern. Die Personalisierungsdaten werden in einer Datenbank gespeichert und zum Darstellen von Seiten verwendet. Folglich verfügen Benutzer über viele Möglichkeiten für böswillige Aktivitäten in Bezug auf den Inhalt einer Website. Benutzer, die auf den freigegebenen Personalisierungsbereich zugreifen können, können sogar die Darstellung der Seiten für alle Benutzer ändern.

Wenn eine bestimmte Seite (z. B. eine der allgemeinen Seiten auf einer Portalwebsite) Webparts-Features verwendet, für die Seite jedoch keine Personalisierung erforderlich ist, empfiehlt es sich, die Personalisierung zu deaktivieren, da somit die Leistung erhöht und die Gefährdung Ihrer Website durch Sicherheitsrisiken verringert wird. Weitere Informationen finden Sie unter Gewusst wie: Deaktivieren der Webparts-Personalisierung.

Authentifizieren von Benutzern für die Personalisierung

Für die Personalisierung sind authentifizierte Benutzer erforderlich. Für anonyme Benutzer kann keine Personalisierung aktiviert werden. Wenn alle Personalisierungs- und Webpartsfunktionen zur Verfügung stehen sollen, muss Ihre Website daher die Windows-basierte oder formularbasierte Authentifizierung verwenden. Informationen zu Authentifizierungsoptionen finden Sie unter Grundlegende Sicherheitsmaßnahmen für ASP.NET-Webanwendungen. Informationen zum Einrichten einer Website mit dem neuen Mitgliedschaftsfeature (das die Formularauthentifizierung verwendet) finden Sie unter Verwalten von Benutzern durch Mitgliedschaft.

Gewähren von minimalem Zugriff auf die freigegebene Personalisierung

Webparts-Personalisierungsänderungen gelten stets für einen angegebenen Bereich bzw. Umfang von Benutzern. Änderungen innerhalb des Benutzerbereichs sind nur für den Benutzer sichtbar, der die Änderungen vornimmt. Änderungen innerhalb des freigegebenen Bereichs sind für alle Benutzer sichtbar. Der freigegebene Personalisierungsbereich steht zur Verfügung, damit Benutzer mit einer Manager- oder Administratorrolle Änderungen an einer Seite vornehmen können, die für alle Benutzer einer Website gelten. Standardmäßig wird allen Benutzern der Zugriff auf den freigegebenen Bereich verweigert. Es sollte nur ausgewählten Benutzern der Zugriff gewährt werden. Dies muss explizit in der Konfigurationsdatei einer Website erfolgen. Weitere Informationen finden Sie unter Gewusst wie: Aktivieren freigegebener Personalisierung von Webparts-Seiten.

Verwenden von getesteten, vertrauenswürdigen Steuerelementen

Da Webparts leistungsfähige Funktionen für Benutzer bereitstellen, beispielsweise die Möglichkeit, einer Seite neue Serversteuerelemente hinzuzufügen, sollten Entwickler genau abwägen, welche Serversteuerelemente sie in einer Webparts-Anwendung verwenden. Serversteuerelemente, insbesondere von Dritten oder Lieferanten, sollten genau überprüft und getestet werden, damit gewährleistet ist, dass sie für die Verwendung in einer Webparts-Anwendung vertrauenswürdig sind. Nehmen Sie beispielsweise an, dass ein bestimmtes Serversteuerelement fehlerhaft entworfen wurde und in der Speicherauslastung ineffizient ist. Wenn Sie dieses Steuerelement einem Webparts-Katalog hinzufügen, können es Benutzer einer Webseite hinzufügen. Da einer Seite ein Steuerelement in einem Katalog beliebig oft hinzugefügt werden kann (mehrere Instanzen), kann ein Benutzer das ineffiziente Steuerelement mehrmals hinzufügen, wodurch letztendlich ein Denial of Service-Angriff generiert wird, wenn die Seite versucht, mehrere Instanzen des Steuerelements zu verarbeiten. Weitere Informationen zu Webparts-Katalogen finden Sie unter dem Referenzthema für die CatalogPart-Klasse.

Verwenden von Autorisierung und Filtern für Steuerelemente

Webparts verfügen über ein Feature, mit dem Sie die Autorisierungsstufe für die Serversteuerelemente zum Erstellen der Benutzeroberfläche der Webparts-Seiten festlegen und überprüfen können. Wenn ein Steuerelement entsprechend den von Ihnen festgelegten Kriterien autorisiert ist, wird es auf der Seite angezeigt. Wenn es auf einer niedrigeren Stufe oder gar nicht autorisiert ist, können Sie seine Darstellung ändern oder es vollständig ausblenden. Nehmen Sie beispielsweise an, einem Benutzer wurde die Administratorrolle zugewiesen. Sie möchten ein bestimmtes Serversteuerelement nur für den Administrator anzeigen lassen. Mithilfe der Webparts-Features für Autorisierung und Filtern können Sie sicherstellen, dass dieses Steuerelement nur einem Administrator angezeigt und für andere Benutzer ausgeblendet wird. Die wichtigsten Mechanismen zum Verwenden von Autorisierung und Filtern sind die AuthorizationFilter-Eigenschaft der WebPart-Klasse sowie die IsAuthorized-Methode und die OnAuthorizeWebPart-Methode der WebPartManager-Klasse.

Codieren von Zeichenfolgentyp-Eigenschaften in Bearbeitungssteuerelementen

Ein einzigartiges Feature von Webparts besteht darin, dass Endbenutzer auf einer Seite in einen Bearbeitungsmodus wechseln und ein Serversteuerelement durch Ändern des Layouts, der Darstellung, des Verhaltens und der personalisierbaren Eigenschaftenwerte bearbeiten können. Dies stellt jedoch ein Risiko dar, da ein böswilliger Benutzer möglicherweise die Möglichkeit der Bearbeitung von Zeichenfolgentyp-Eigenschaften ausnutzen und ungeeignete Daten einfügen oder einen Script-Injection-Angriff ausführen könnte. Wenn Sie benutzerdefinierte EditorPart-Steuerelemente zum Bearbeiten von Serversteuerelementen erstellen und wenn alle personalisierbaren Eigenschaften in einem angegebenen Serversteuerelement einem Zeichenfolgentyp entsprechen oder einen Zeichenfolgenkonverter verwenden, sollte das EditorPart-Steuerelement die Zeichenfolgendaten aus Sicherheitsgründen codieren, bevor sie der Eigenschaft zugewiesen werden. Ein Beispiel finden Sie in der Referenzdokumentation zur HtmlEncode-Methode.

Sdílet prostřednictvím