Was ist der Sinn eines Policy Servers? (Silverlight)

Question

Ich habe mich mit Silverlight Sockets herumgeschlagen und nachdem ich mir am Kopf ein wenig darüber gekratzt habe, warum meine Verbindungen verweigert wurden, wurde mir klar, dass ich einen Policy Server einrichten musste. Silverlight stellt eine Verbindung zum Policy Server-Port auf dem Host her, der durch die Socket-Verbindung angegeben wurde. Der Richtlinienserver gibt eine XML-Datei zurück, die angibt, welcher Zugriff auf diesen Host erlaubt ist.

Verstehe ich das richtig? Worauf kommt es an? Könnte kein böswilliger Benutzer einfach die Richtliniendatei ignorieren und tun, was sie wollen?

alt text http://www.netortech.com/Content/policy.jpg

Answer 1

Ich fand endlich einen guten Grund, dies zu tun.

Silverlight-Apps haben die Möglichkeit, sehr schnell verteilt/ausgeführt zu werden. Sprich, als Werbung auf einer beliebten Seite zum Beispiel. In diesem Fall wäre es für jemanden sehr einfach, eine Silverlight-App zu verwenden, um eine DoS-Attacke auf einen Host auszuführen, indem er sie einfach einem Werbeanbieter gibt. Da jedoch alle Silverlight-Apps zuerst die Richtliniendatei für den Host prüfen, wird dadurch begrenzt, auf welche Hosts und Dienste diese Art von Angriffen abzielen kann.

Answer 2

Quote:

Verwendung für die Kommunikation Cross-Domain erfordert gegen verschiedene Arten von Sicherheitslücke schützt, die verwendet werden können Web-Anwendungen zu nutzen. Cross-Site-Fälschung ist eine Klasse von Exploits, die zu einer Bedrohung wird, wenn domänenübergreifende Aufrufe zugelassen werden. Bei diesem Exploit handelt es sich um eine bösartige Silverlight-Steuerung, die ohne Wissen des Benutzers nicht autorisierte Befehle an einen Dienst eines Drittanbieters überträgt. Um Cross-Site-Request-Forgery zu verhindern, erlaubt Silverlight standardmäßig nur die Kommunikation über den Ursprungsort für alle Anfragen außer Bildern und Medien. Beispielsweise kann ein Silverlight-Steuerelement, das unter http://contoso.com/mycontrol.aspx gehostet wird, standardmäßig nur auf Dienste in derselben Domäne zugreifen, z. B. http://contoso.com/service.svc, aber kein Dienst unter http://fabrikam.com/service.svc. Dadurch wird verhindert, dass ein schädliches Silverlight-Steuerelement, das in der Domäne http://contoso.com gehostet wird, nicht autorisierte Vorgänge auf einem Dienst aufruft, der auf der Domäne http://fabrikam.com gehostet wird.

Damit ein Silverlight-Steuerelement auf einen Dienst in einer anderen Domäne zugreifen kann, muss der Dienst explizit den domänenübergreifenden Zugriff zulassen. Ein Dienst gibt an, dass die bereitgestellten Operationen von einem Silverlight-Steuerelement problemlos aufgerufen werden können, ohne potenziell schädliche Auswirkungen auf die Daten zu haben, die vom Dienst gespeichert werden.

---

EDIT: basierend auf Kommentar/Frage ...

Ich werde einfach mein wahrscheinlich unvollkommenes Verständnis für die Situation geben, aber das macht Sinn für mich.

Ein Browser ist im Allgemeinen davon abhängig, wohin er Sie leiten kann, indem er es schwierig macht, auf einen anderen Host als den, der die HTTP-Seiten bedient, zuzugreifen. Dies gilt unabhängig davon, welche Ressource gerade diskutiert wird. Und diese Einschränkungen müssen durch Rückschlüsse auf alles andere, das im Kontext des Browsers/der Webseite ausgeführt wird, einschließlich Silverlight, angewendet werden. Dies ist nur eine Extrapolation eines bestehenden Mechanismus, um ausländische Referenzen zuzulassen.

Ich bin mir nicht sicher, wie Sie beabsichtigen, einen "Dienst" von einem "Socket" zu unterscheiden. Im Allgemeinen verwenden Dienste Sockets; Es gibt einen Prozess (Dienst oder sonstwie), der auf einem Host sitzt und zusieht, wie er Verbindungen an einem Port herstellt. Eine Art von Verbindung ist eine Steckdose.