Freigeben über


Dieser Artikel wurde maschinell übersetzt.

Silverlight-Sicherheit

Sicherheit für Ihre Silverlight-Anwendungen

Josh Twist

In meiner Rolle als Berater mit Microsoft Services habe ich reguläre Diskussionen mit Kunden und Partnern über Anwendungssicherheit.In diesem Artikel werde ich einige der Designs untersuchen, die in diesen Diskussionen auftreten.Insbesondere ich konzentriere auf die neue Herausforderungen Programmierer Gesicht beim Sichern von Silverlight-Anwendungen, und ich werde berücksichtigen, in denen Entwicklungsteams Ihre Ressourcen konzentrieren sollten.

Dieser Artikel berührt auf vielen technischen Konzepte, die Sie feststellen, an anderer Stelle (einschließlich dieses Magazin) ausführlicher behandelt.Aus diesem Grund wird nicht in diesen Themen hervorragende technische ausführlich untersucht.Stattdessen wird das Ziel des Artikels zum “ Verbinden die Punkte ” und anzeigen, wie Sie diese Konzepte zum Sichern von Ihren Anwendungen nutzen können.

Beim Planen der Sicherheit für eine Anwendung, es empfiehlt sich, drei vorstellen A: Authentifizierung, Autorisierung und Überwachung.

Authentifizierung ist der Vorgang der Bestätigung, dass Benutzer, der er vorgibt sind zu sein.Dies erfolgt i. d. r. mit einem Benutzernamen und Kennwort.

Authorisierung ist der Prozess der Bestätigung, dass ein Benutzer, einmal authentifiziert, tatsächlich verfügt die entsprechenden Berechtigungen Ausführen eines bestimmten Aktion oder eine bestimmte Ressource zugreifen.

Überwachung ist der Vorgang, bei der Verwaltung eines Datensatzes der Aktivität, so dass Aktionen und Anforderungen bei einem System können nicht vom Benutzer verweigert werden.

Ich werde mich auf die ersten beiden, Authentifizierung und Autorisierung im Kontext einer Silverlight-Anwendung konzentrieren.Da dies eine Rich Internet Application (RIA) ist, die Mehrzahl der in diesem Artikel beschriebenen Konzepte gelten gleichermaßen für Asynchronous JavaScript und XML (AJAX) oder andere RIA Ansätze.Es wird erläutert, wie Sie den unerwünschten Zugriff auf die Dateien Ihrer Silverlight-Anwendung verhindern können.

Topologie

Silverlight ist ein Cross-Browser-Plug-In, die nutzt viele grafische Konzepte, die pioneered von Windows Presentation Foundation (WPF), aktivieren Webentwickler erstellen reichhaltige Benutzerfunktionalität weit über was nur mit HTML und JavaScript möglich ist.

Im Gegensatz zu ASP.NET, ist Silverlight eine Technologie clientseitige, so dass Sie auf Computern Benutzer ausgeführt wird.Silverlight-Entwicklung hat also wohl mehr gemeinsam mit Windows Forms- oder WPF als mit ASP.NET.In vielerlei Hinsicht ist dies eine der größten Vorteile des Silverlight, wie viele der Probleme durch zustandsfrei sind Webanwendungen werden entfernt.Jedoch, da der Benutzeroberflächencode auf Clientcomputern ausgeführt wird, können nicht Sie es nicht mehr vertrauen.

Services

Im Gegensatz zu Windows Forms Silverlight funktioniert innerhalb der Sandbox-Browser, und hat einen reduzierten Satz von Funktionen, so dass es sich um einen höheren Grad an Sicherheit bietet (Obwohl in Silverlight 4 können Benutzer bestimmter Anwendungen als vertrauenswürdig identifizieren und stufen Sie die Programme Privilegien, um COM-Interop zu ermöglichen).Aus diesem Grund kann nicht Silverlight zu einer Datenbank direkt, verbinden, so dass Sie eine Ebene von Diensten erstellen müssen, die Zugriff auf Ihre Daten und Geschäftslogik bereitstellen.

In der Regel Sie Host diese Dienste auf dem Webserver, so wie Sie mit Ihrer Formulare ASP.NET Web for example würde.Angesichts der Tatsache, dass Silverlight-Code auf der falschen Seite der Vertrauensgrenze zwischen Ihren Servern und der realen Welt ausgeführt wird (siehe Abbildung 1), sollte das Ziel der Aufwand für Ihr Team immer zum Absichern der Dienste.

Silverlight wird auf der falschen Seite des Trust-Grenze

Abbildung 1 Silverlight wird auf der falschen Seite des Trust-Grenze

Es hat wenig Sinn gründliche Sicherheitsüberprüfungen innerhalb der Silverlight-Code selbst implementieren.Nachdem alle es wäre einfach für einen Angreifer, sofort mit der Silverlight-Anwendung vollständig und Ihrer Dienste direkt aufrufen, alle Sicherheitseinstellungen Seite stepping misst Sie implementiert.Eine Person in böswilliger Absicht konnte auch ein Dienstprogramm wie Silverlight Spy++ oder Debugtools für Windows verwenden, um das Verhalten der Anwendung zur Laufzeit zu ändern.

Dies ist eine wichtige Erkenntnis – ein Dienst kann nicht Vergewissern Sie sich welche Anwendung es aufruft oder kennen, die die Anwendung noch nicht in irgendeiner Weise geändert wurde.Daher haben Ihre Dienste, um sicherzustellen, dass:

  • Der Aufrufer ist ordnungsgemäß authentifiziert werden.
  • Der Aufrufer ist berechtigt, den angeforderten Aktion auszuführen

Die meisten der in diesem Artikel behandelt diesen Gründen zum Absichern von Dienste in einer Weise, die mit Silverlight kompatibel ist.Insbesondere werde ich zwei verschiedene Arten von über ASP.NET in Microsoft IIS gehostete Dienste berücksichtigen.Der erste Typ, Dienste, die mit Windows Communication Foundation (WCF) erstellt bietet ein einheitliches Programmiermodell zum Erstellen von Diensten.Die zweite WCF Data Services (früher (ADO.NET Data Services), baut auf WCF in dem Sie die Daten mithilfe von HTTP-Standardverben ein Ansatz, bekannt als Representational State Transfer (REST) schnell bereitstellen können.

Natürlich, wenn Sicherheit nicht gewünscht ist, ist es immer empfehlenswert, um die gesamte Kommunikation zwischen Clients und Servern zu verschlüsseln.Die Verwendung von HTTPS/SSL-Verschlüsselung wird empfohlen und davon ausgegangen, dass in diesem Artikel.

Heute sind die beiden am häufigsten verwendeten Authentifizierungsmethoden Webentwickler auf der Microsoft-Plattform verwenden Windows-Authentifizierung und Formularauthentifizierung.

Windows-Authentifizierung

Windows-Authentifizierung nutzt die lokale Sicherheitsautorität oder Active Directory, um Benutzeranmeldeinformationen zu überprüfen.Dies ist ein großer Vorteil in vielen Szenarios; Dies bedeutet, dass Benutzer mit Tools, die bereits vertraut sind, um Systemadministratoren zentral verwaltet werden können.Windows-Authentifizierung können Sie ein Schema von IIS, einschließlich basic, Digest, integrierte Authentifizierung (NTLM/Kerberos) und Zertifikate unterstützt.

Integrierte Schema ist die häufigste Auswahl für die Verwendung mit Windows-Authentifizierung, da Benutzer Ihren Benutzernamen und Kennwörter ein zweites Mal bereitgestellt haben.Sobald ein Benutzer bei Windows anmeldet, kann der Browser Anmeldeinformationen in Form von einem Token oder ein Handshake, der bestätigt die Identität der Person weiterleiten.Es gibt einige Nachteile mithilfe integrierter Authentifizierung, da die Client- und Sichtbarkeit der Domäne des Benutzers erforderlich.Daher ist es am besten Intranetszenarios richtet.Obwohl es automatisch mit Microsoft Internet Explorer arbeitet, sind andere Browser, wie z. B. Mozilla Firefox, darüber hinaus zusätzliche Konfigurationsmaßnahmen erforderlich.

Beide Basis- und Digestauthentifizierung, die in der Regel müssen Benutzer Ihren Benutzernamen und Kennwörter eingeben, wenn eine Sitzung mit Ihrer Website zu initiieren.Da beide Teil der HTTP-Spezifikation, Funktionsweise ist jedoch in den meisten Browsern und selbst wenn über außerhalb Ihrer Organisation.

Silverlight nutzt den Browser für die Kommunikation, damit Windows-Authentifizierung handelt es sich einfach mit der soeben beschriebenen IIS-Authentifizierungsmethoden implementiert.Eine ausführliche Beschreibung der Vorgehensweise, empfehle ich die Schritt-für-Schritt-Anleitung lesen “ How to: Mit Windows-Authentifizierung und TransportCredentialOnly in WCF von Windows Forms BasicHttpBinding verwenden ” zur MSDN.Microsoft.com/library/cc949012.In diesem Beispiel wird eine Windows Forms-Testclient tatsächlich verwendet, aber der gleiche Ansatz, die auf Silverlight angewendet wird.

Formularauthentifizierung

Die Formularauthentifizierung ist ein Mechanismus, der einfache Unterstützung für benutzerdefinierte Authentifizierung in ASP.NET bietet.Daher ist es speziell für HTTP, was bedeutet, dass es auch in Silverlight einfach zu verwenden ist.

Der Benutzer gibt die Kombination eine aus Benutzername und Kennwort, die zur Überprüfung an den Server gesendet wird.Der Server überprüft die Anmeldeinformationen für eine vertrauenswürdige Datenquelle (oft auf eine Datenbank von Benutzern) und gibt ein Cookie FormsAuthentication-korrekt sind.Der Client sendet dann dieses Cookie mit nachfolgenden Anforderungen.Das Cookie ist signiert und verschlüsselt, dass nur der Server entschlüsselt werden kann – böswilliger Benutzer kann weder entschlüsseln noch ihn manipulieren.

Genau wie Sie Formularauthentifizierung aufrufen, hängt die Implementierung der Anmeldebildschirm Ihres.Wenn Sie ein ASP.NET Web-Formular, die für Ihre Silverlight-Anwendung umleitet verwendet haben, nachdem der Benutzer Anmeldeinformationen validiert wurden, haben Sie z. B. wahrscheinlich nicht mehr Authentifizierung Arbeit tun.Das Cookie bereits wird wurden gesendet an den Browser und die Silverlight-Anwendung wird weiterhin das Cookie verwenden, wenn eine Anforderung an diese Domäne vornehmen.

Wenn Sie den Anmeldebildschirm innerhalb der Silverlight-Anwendung implementieren möchten, müssen Sie einen Dienst zu erstellen, der Ihre Authentifizierungsmethoden verfügbar macht und sendet den entsprechenden Cookies.Glücklicherweise ASP.NET bereits bietet, benötigen Sie – der Authentifizierungsdienst.Sie müssen nur in Ihrer Anwendung zu aktivieren.Ausführliche Informationen, die ich empfehle lesen “ How to: Verwenden Sie die Authentifizierung in ASP.NET Service anmelden in über Silverlight-Anwendungen ” am MSDN.Microsoft.com/library/dd560704(VS.96).

Ein weiteres großartiges Feature der ASP.NET-Authentifizierung ist der Erweiterbarkeit.Ein Mitgliedschaftsanbieter beschreibt den Mechanismus, durch den der Benutzername und Kennwort überprüft werden.Glücklicherweise stehen eine Reihe von Mitgliedschaftsanbietern als Bestandteil von ASP.NET, einschließlich eines, das mithilfe von SQL Server-Datenbanken und eine andere Active Directory verwendet.Wenn ein Anbieter, der Ihre Anforderungen erfüllt nicht verfügbar ist, ist jedoch einfach um eine benutzerdefinierte Implementierung zu erstellen.

ASP.NET-Autorisierung

Nachdem der Benutzer authentifiziert werden, ist es wichtig, um sicherzustellen, dass nur Sie versuchen können, die Dienste aufrufen.Normaler WCF-Dienste sowohl WCF Data Services sind durch eine .svc-Datei in ASP.NET-Anwendungen dargestellt.In diesem Beispiel die Dienste sind dabei, über ASP.NET in IIS gehostet werden, und ich werde zeigen, wie Sie Ordner zum Sichern des Zugriffs auf die Dienste verwenden können.

Auf diese Weise ist Sichern der .svc-Dateien ein wenig verwirrend, da standardmäßig eine Anforderung für eine solche Datei tatsächlich ein Großteil der ASP.NET-Pipeline umgehen der Autorisierung Module überspringt.Dies hat zur Folge, um viele ASP.NET-Features abhängen, müssen Sie ASP.NET-Kompatibilitätsmodus aktivieren.Die WCF-Datendienste Einzugsermächtigung in jedem Fall, dass es zu aktivieren.Ein einfacher Schalter in der Konfigurationsdatei wird die Aufgabe erreicht:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
<system.web>
    <authorization>
        <deny users="?"/>
    </authorization>
</system.web>

Mit ASP.NET-Kompatibilität aktiviert ist es möglich, um den Zugriff auf nicht authentifizierte Benutzer zu verhindern, mithilfe den Authorization-Abschnitt einer web.config-Datei, die auch im vorherigen Codeausschnitt gezeigt.

Wenn Sie die Formularauthentifizierung verwenden, muss der Entwickler vorstellen sorgfältig darüber, welche Teile der Website auch für nicht authentifizierte Benutzer zugänglich sein müssen.Beispielsweise, wenn alle Teile auf nur authentifizierte Benutzer beschränkt werden, wird wie ein nicht authentifizierter Benutzer anmelden?

Es ist oft am einfachsten, eine Ordnerstruktur erstellen, die Ihre grundlegende Autorisierungsanforderungen unterstützt.In diesem Beispiel habe ich einen “ Secured ”-Ordner, der die MyWcfService.svc und MyWcfDataService.svc enthält erstellt, und ich habe eine web.config-Datei bereitgestellt.In Abbildung 2 Sie sehen können, die Ordnerstruktur und der vorherigen Codeausschnitt zeigt den Inhalt der Datei web.config.

Sichere Ordner mit der Datei "Web.config"
Abbildung 2 Sichere Ordner mit der Datei "Web.config"

Beachten Sie, dass im Stammverzeichnis der Anwendung muss der anonyme Zugriff zulässig, andernfalls Benutzer nicht in der Lage, die Anmeldeseite zu erreichen.

Für Sites, die über die Windows-Authentifizierung kann Dinge etwas einfacher ist in dieser Hinsicht wie die Authentifizierung erfolgt ist, bevor der Benutzer erhält daher keine Notwendigkeit für eine bestimmte Anmeldeseite besteht innerhalb der Anwendung enthaltenen Ressourcen.Bei diesem Ansatz ist es tatsächlich möglich ist, um den Zugriff auf Dienste detailliertere derart, so dass nur bestimmte Gruppen von Benutzern oder Rollen für den Zugriff auf Ressourcen zu beschränken.Weitere Informationen finden Sie unter “ ASP.NET-Autorisierung ” (msdn.microsoft.com/library/wce3kxhd).

In diesem Beispiel implementiert die Autorisierung auf etwas, jedoch auf Ordnerebene Autorisierung allein ist viel zu grobe auf den meisten Szenarios zu verlassen.

Autorisierung in WCF-Dienste

Mit dem PrincipalPermission-Attribut ist eine einfache Möglichkeit, Anforderungen, die eine Invoker einer Microsoft .NET Framework-Methode innerhalb einer bestimmten Rolle sein.In diesem Codebeispiel wird veranschaulicht, wie dies auf einen ServiceOperation in WCF angewendet werden kann, in denen der aufrufende Benutzer Teil der “ OrderApprovers ”-Rolle sein muss:

[PrincipalPermission(SecurityAction.Demand, Role = "OrderApprovers")]
public void ApproveOrder(int orderId)
{
  OrderManag-er.ApproveOrder(orderId);
}

Dies ist problemlos in Anwendungen implementiert, die Windows-Authentifizierung, verwenden um die vorhandene Funktion zum Erstellen von Active Directory-Gruppen zum Organisieren von Benutzern zu nutzen. Mit Anwendungen, die Formularauthentifizierung verwenden ist es möglich, ein weiteres großartiges anbieterbasierte Feature von ASP.NET nutzen: RoleProviders. Erneut, eine Reihe von diese verfügbar sind, aber falls keine geeignet sind, können Sie implementieren eine eigene.

Natürlich ist sogar pro Methode Autorisierung selten genug um Ihre Sicherheit erfüllen müssen, und Sie können immer zurückgreifen prozeduralem Code innerhalb Ihrer Dienste schreiben, wie in Abbildung 3.

Abbildung 3 Mithilfe von prozeduralen Code zum Implementieren von bestimmten Autorisierung

Public void CancelOrder(int orderId)
{
  // retrieve order using Entity Framework ObjectContext
  OrdersEntities entities = new OrdersEntities();
  Order orderForProcessing = entities.Orders.Where(o => o.Id == 
    orderId).First();

  if (orderForProcessing.CreatedBy != 
    Thread.CurrentPrincipal.Identity.Name)
  {
    throw new SecurityException(
      "Orders can only be canceled by the user who created them");
  }

  OrderManager.CancelOrder(orderForProcessing);
}

WCF eine hochgradig erweiterbare Plattform handelt, und wie bei allen Dinge in WCF viele Ansätze zum Implementieren von Autorisierung in Ihre Dienste vorhanden sind. Dominick Baier und Christian Weyer erläutert eine Reihe von Möglichkeiten im Detail in der Ausgabe vom Oktober 2008 von MSDN Magazine. Im Artikel “ Autorisierung in WCF-Based Services ” (MSDN.Microsoft.com/magazine/cc948343), sogar Ventures in anspruchsbasierte Sicherheit, eine strukturierte Möglichkeit zum Organisieren von Autorisierung in Ihrer Anwendung.

Autorisierung in WCF Data Services

WCF Data Services, wie der Name schon sagt, baut auf WCF REST-basierter Zugriff auf eine Datenquelle – vielleicht in den meisten Fällen eine LINQ-SQL oder LINQ, Entity Framework-Datenquelle. Kurz gesagt, ermöglicht dies ermöglichen den Zugriff auf Ihre Daten unter Verwendung eines URLs, die Zuordnungen auf die Entität Sets zur Verfügung gestellt von Ihrer Datenquelle (ein Entitätssatz wird i. d. r. eine Tabelle in der Datenbank). Berechtigungen für diese Entität-Sätze können innerhalb von Diensten Code-Behind-Datei konfiguriert werden. Abbildung 4 zeigt den Inhalt der Datei MyWcfDataService.svc.cs.

Abbildung 4 Eine WCF Data Services-CodeBehind-Datei, mit der Konfiguration der Entität festlegen Zugriffsregeln

Public class MyWcfDataService : DataService<SalesEntities>
{
  // This method is called only once to initialize service-wide policies.
  Public static void InitializeService(IDataServiceConfiguration config)
  {
    config.SetEntitySetAccessRule("Orders", EntitySetRights.AllRead);
    config.SetEntitySetAccessRule("Products", EntitySetRights.AllRead | 
      EntitySetRights.WriteAppend | EntitySetRights.WriteDelete);
  }}

Hier habe ich lesen Berechtigungen über die Bestellungen Entitätssatz angegeben und konfiguriert die Produkte Entität festgelegt werden, um vollständig gelesen haben, das Einfügen neuer Datensätze zu ermöglichen und das Löschen vorhandener Datensätze.

Jedoch, da WCF Data Services automatisch Zugriff auf Ihre Daten auf der Grundlage dieser Konfiguration wiedergibt, müssen Sie direkten Zugriff auf den Code so, dass es ist offensichtlich bestimmten Autorisierungslogik implementieren nicht. WCF Data Services unterstützt Interceptors, mit die Entwickler zwischen dem Client und der Datenquelle Logik implementieren können. Beispielsweise ist es möglich, eine Abfrage Interceptor anzugeben, die die Ergebnisse für eine bestimmte Entität filtert. Das Beispiel in Abbildung 5 zeigt zwei Abfrage-Interceptors der MyWcfDataService-Klasse hinzugefügt.

Abbildung 5 Abfrage-Interceptors in WCF Data Services

[QueryInterceptor("Products")]
Public Expression<Func<Product, bool>> OnQueryProducts()
{
  String userName =ServiceSecurityContext.Current.PrimaryIdentity.Name;
  return product => product.CreatedBy == userName;
}

[QueryInterceptor("Orders")]
Public Expression<Func<Comments, bool>> OnQueryOrders()
{
  bool userInPrivateOrdersRole = 
    Thread.CurrentPrincipal.IsInRole("PrivateOrders");
  return order => !order.Private|| userInPowerUserRole;
}

Die erste gilt für die Produkte, Entität festgelegt, und stellen Sie sicher, dass Benutzer nur die von Ihnen erstellten Produkte abrufen können. Die zweite wird sichergestellt, dass nur Benutzer in der Rolle PrivateOrders lesen können Aufträge privat gekennzeichnet.

Ebenso ist es möglich, die Änderung Interceptors angeben, die ausgeführt werden, bevor eine Entität eingefügt, geändert oder gelöscht werden, wie hier gezeigt:

[ChangeInterceptor("Products")]
public void OnChangeProducts(Product product, UpdateOperations operations
{
  if (product.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
  {
    throw new DataServiceException(
      "Only products created by a user can be deleted by that user");
  }
}

Auf der ersten Anzeige der Interceptor OnChangeProducts Änderung in diesem Codebeispiel zum Offenlegen einer Sicherheitslücke wird angezeigt, weil Daten aus einer externen Quelle übergeben die Implementierung abhängig – insbesondere den “ Produkt ”-Parameter. Aber wenn Sie eine Entität in WCF Data Services zu löschen, wird nur ein Entitätsschlüssel vom Client an den Server übergeben. Bedeutet der Entität, die in diesem Fall das Produkt, erneut aus der Datenbank abgerufen werden und ist daher vertraut werden kann.

Der Produkt-Parameter ist jedoch bei der Aktualisierung einer vorhandenen Entität (z. B., wenn der Parameter Operationen UpdateOperations.Change entspricht), die de-serialized Entität, die vom Client gesendeten aus diesem Grund darf Sie nicht vertrauenswürdig. Die Client-Anwendung möglicherweise geändert wurden, um die CreatedBy-Eigenschaft dieses bestimmten Produkts zu einer zerstörerischen Benutzer eigene Identität, wodurch erhöhen die Usurper Berechtigungen angeben. Könnte, die Änderung eines Produkts von einer Person, die in der Lage, dazu sein dürfte nicht. Um dies zu vermeiden, empfehle ich, dass Sie die ursprüngliche Entität aus der vertrauenswürdigen Datenquelle basierend auf der Entitätsschlüssel allein, wie in re-fetchAbbildung 6.

Abbildung 6 Eine Änderung Interceptors verhindern nicht autorisierter INSERT, Update und DELETE-Operationen

[ChangeInterceptor("Products")]
Public void OnChangeProducts(Product product, UpdateOperations operations)
{
  if (operations == UpdateOperations.Add)
  {
    product.CreatedBy = Thread.CurrentPrincipal.Identity.Name;
  }
  else if (operations == UpdateOperations.Change)
  {
    Product sourceProduct = this.CurrentDataSource.Products.Where(p =>
      p.Id == product.Id).First();
    if (sourceProduct.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
    {
      throw new DataServiceException(
        "Only records created by a user can be modified by that user");
    }
  }
  else if (operations == UpdateOperations.Delete &&
    product.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
  {
    Throw new DataServiceException(
      "Only records created by a user can be deleted by that user");
  }
}

Da diese Implementierung so sehr auf die CreatedBy-Eigenschaft der Product-Entität beruht, ist es sehr wichtig, dass dieser in ein verlässlicher Weg von dem Moment erzwungen ist die Daten erstellt werden.Abbildung 6 auch veranschaulicht, wie dies durch Überschreiben alle vom Client für eine Add-Operation übergebenen Wert erreicht werden kann.

Beachten Sie, wie im Beispiel wird derzeit steht, Vorgänge des Typs UpdateOperations.Change behandeln ein Problem wäre.In Abbildung 4, der Dienst wurde so konfiguriert, dass nur AllRead, WriteAppend (Insert) und WriteDelete Aktionen auf den Artikel Entität Sätzen auftreten können.Die ChangeInterceptor würden daher nie für einen Vorgang ändern aufgerufen werden, wie der Dienst sofort jede Anforderung an eine Product-Entität an diesem Endpunkt ändern ablehnen würde.So aktivieren Sie Updates, durch den Aufruf von SetEntitySetAccessRule in Abbildung 4 müssten WriteMerge, WriteReplace oder beides enthalten.

Domänenübergreifende Authentifizierung

Das Silverlight-Plug-In kann domänenübergreifende HTTP-Anforderungen vornehmen.Ein Cross-Domain-Aufruf ist eine HTTP-Anforderung an eine andere Domäne als diejenige, die von dem die Silverlight-Anwendung heruntergeladen wurde.Die Möglichkeit, solche Aufrufe hat üblicherweise als ein Sicherheitsrisiko angesehen wurde.Es ermöglicht, einen böswilligen Entwickler stellen Anforderungen an einen anderen Standort (z. B. Ihre online-Banking-Site) und Automatisches Weiterleiten von jeder dieser Domäne zugeordneten Cookies.Potenziell, könnte dies die Angreifer zu einem anderen angemeldeten Sitzung innerhalb desselben Browserprozesses zugreifen.

Aus diesem Grund haben Websites zu nutzen domänenübergreifende Aufrufe über die Bereitstellung cross-domain Richtliniendatei ermöglicht.Dies ist eine XML-Datei, die beschreibt, welche Arten von domänenübergreifende Aufrufe zulässig sind, z. B. von welcher Domäne, auf welche URLs.Weitere Informationen finden Sie unter “ Making a Service Available Across Domain Boundaries ” (msdn.microsoft.com/library/cc197955(VS.95)).

Sie sollten stets vorsichtig bei der Entscheidung, vertraulichen Informationen auf domänenübergreifende Aufrufe verfügbar zu machen.Wenn Sie feststellen, dass dies ein Szenario wird zusammen mit der Authentifizierung unterstützt werden müssen, es ist jedoch wichtig zu beachten, dass die cookiebasierte Authentifizierung Methoden – wie weiter oben beschriebenen Formularauthentifizierung – nicht mehr geeignet sind.Sie könnten Sie stattdessen Nutzung Nachricht Anmeldeinformationen, wobei der Benutzername und Kennwort an den Server übergeben und mit jedem Aufruf überprüft.WCF unterstützt dies durch den TransportWithMessageCredential-Sicherheitsmodus.Weitere Informationen finden Sie unter “ How to: Verwenden Sie Message Anmeldeinformationen zum Sichern eines Dienstes für die Silverlight-Anwendungen ” (MSDN.Microsoft.com/library/dd833059(VS.95)).

Natürlich entfernt dieses Ansatzes ASP.NET während des Authentifizierungsprozesses vollständig, so dass es schwierig ist, zusammen mit ASP.NET 
authorization, die weiter oben erläuterten nutzen.

Sichern von Silverlight-XAP-Dateien

Personen, die sich Gedanken über Silverlight Sicherheit oft bitten, “ wie kann ich meine XAP-Dateien schützen? ” Manchmal ist die Motivation hinter dieser Abfrage, das im Code enthaltene geistiges Eigentum geschützt.In diesem Fall müssen Sie betrachten verbergen Personen zum Verstehen des Codes erschwert.

Eine andere häufige Motivation ist, um zu verhindern, dass böswillige Benutzer befragen den Code und die Silverlight-Anwendung verstehen, erteilen ihm das Potenzial, um Ihre Dienste zu unterbrechen.

Ich Antworten in der Regel dadurch mit zwei Punkten.Zuerst, es ist, zwar möglich, den Download von Ihrem Silverlight-Anwendung (XAP-Datei) auf authentifizierte und autorisierte Benutzer beschränken besteht kein Grund, diese Benutzer alle weniger böswilligen als nicht authentifizierter Benutzer werden zu vertrauen.Sobald die Anwendung an den Client heruntergeladen wurde, ist absolut nichts mehr Benutzer befragen den Code, bei dem Versuch, Ihre eigenen Privilegien ausweiten oder die Bibliotheken an jemand anderen weiterzuleiten.Verschleierung kann dieser Vorgang etwas schwieriger, aber nehmen nicht gut genug, um Ihre Anwendung sicher ist.

Zweitens ist es sehr wichtig zu bedenken, dass jeder Benutzer, die rechtmäßig Dienste über die Silverlight-Anwendung aufrufen können, auch diese Dienste direkt aufrufen kann z. B. mit einem Internetbrowser und einige JavaScript.Es gibt nichts tun können, um zu verhindern, dass dies geschieht, damit es von größter Bedeutung ist, dass Ihre Sicherheitsbemühungen auf Shoring Sie Ihre Dienste konzentrieren.Dieses Recht verfügen, und es ist unwichtig, was ein böswilliger Benutzer über die Silverlight-Anwendung Code erlangen kann.Trotz allem möchte einige Leute weiterhin sicherstellen, dass nur authentifizierte Benutzer Ihren XAP-Dateien zugreifen können.Dies ist möglich, aber wie einfach es ist, hängt von der Version von IIS, die Sie verwenden und die ausgewählte Authentifizierungsmethode.

Wenn Sie Windows-Authentifizierung verwenden, können Sie problemlos die XAP-Dateien mithilfe des IIS-Verzeichnissicherheit schützen.Wenn Sie jedoch, Sie Formularauthentifizierung verwenden, erhalten die Dinge ein wenig komplizierter.In diesem Fall ist es nach oben um FormsAuthenticationModule abfangen und das Cookie begleitenden jede Anforderung überprüfen und zulassen oder Verweigern des Zugriffs auf die angeforderte Ressource.

Da das FormsAuthenticationModule ein Modul für ASP.NET ist, muss die Anforderung über die ASP.NET-Pipeline für diese Überprüfung stattfinden übergeben.In IIS6 (Windows Server 2003) und frühere Versionen, Anforderungen für XAP-Dateien nicht, in der Standardeinstellung werden weitergeleitet werden über ASP.NET.

IIS7 (Windows Server 2008) eingeführt, die integrierte Pipeline, wodurch alle Anforderungen über die Pipeline von ASP.NET weitergeleitet werden.Wenn Sie können in IIS7 bereitstellen und verwenden Sie einen Anwendungspool im integrierten Pipeline-Modus ausgeführt wird, ist die Sichern der XAP-Dateien nicht schwieriger als das .svc-Dateien sichern, wie weiter oben im Abschnitt „ ASP.NET-Autorisierung beschrieben.Aber wenn Sie für IIS6 oder früher bereitstellen müssen, haben Sie wahrscheinlich einige zusätzliche Aufgaben durchführen.

Ein beliebter Ansatz besteht darin, streaming-die Bytes, die die XAP-Datei durch eine andere Erweiterung bilden, die von die Pipeline von ASP.NET behandelt wird.Die typische Möglichkeit dazu ist über eine IHttpHandler-Implementierung (in einer Datei .ashx).Weitere Informationen finden Sie unter “ Einführung in HTTP-Handlern ” (MSDN.Microsoft.com/library/ms227675(VS.80)).

Ein anderer Ansatz besteht darin, die IIS-Konfiguration zu ändern, so dass der XAP-Dateien über die Pipeline von ASP.NET weitergeleitet werden.Da dies eine nicht trivialen Änderung an der IIS-Konfiguration erforderlich ist, ist der erste Ansatz üblicher.

Berücksichtigen Sie bei der Formularauthentifizierung ein weiteres Problem ist der Anmeldebildschirm.Wenn, wie der vorgeschlagene weiter oben in diesem Artikel, Sie für eine ASP.NET Web Form, sind keine Probleme.Doch wenn Sie den Anmeldebildschirm, um in Silverlight erstellt werden lieber, müssen Sie die Anwendung in Komponenten aufgeteilt.Ein Teil (Login-Modul) muss verfügbar sein, um nicht authentifizierten Benutzern und eine andere (die sichere Anwendung) sollte nur authentifizierten Benutzern zur Verfügung.

Sie können zwei Ansätze nutzen:

  1. Haben Sie zwei separate Silverlight-Anwendungen.Der erste würde 
contain das Anmeldedialogfeld und werden in einem nicht gesicherten Bereich der Website.Bei der erfolgreichen Anmeldung würde dies zu einer Seite eine XAP-Datei in einem sicheren Bereich Ihrer Site angeben leiten Sie anschließend.
  2. Die Anwendung in zwei oder mehrere Module aufteilen.Während des Authentifizierungsprozesses würde den ursprünglichen XAP befindet sich in einem nicht gesicherten Bereich Ihrer Site durchgeführt werden.Wenn dies erfolgreich ist, würde die XAP-Datei von einem sicheren Bereich eine nachfolgende anfordern, die dynamisch in der Silverlight-Anwendung geladen werden konnte.Ich kürzlich Blogged dazu, wie Sie diese ( tun können thejoyofcode.com/How_to_download_and_crack_a_Xap_in_Silverlight.aspx).

Josh Twist ist principal Consultant im Microsoft Application Development Consulting-Team in Großbritannien und können am Blogging gefunden werden thejoyofcode.com.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Zulfiqar Ahmed, Chris Barker und Simon Ince