Immer wieder kommt die Frage, warum eigentlich dieser Aufwand mit den Cross-Domain-Policy Dateien (clientaccesspolicy.xml bei Silverlight und crossdomain.xml bei Flash, Java und Silverlight) betrieben werden muss, möchte man extern kommunizieren. Also wenn eine Inhalt von (Sub-)Domain A auf einen Inhalt von (Sub-)Domain B zugreifen möchte: Meist ist es dabei auch unerheblich, ob es sich bei dem zu ladenden Inhalt um Bild, Sound, Text, Video oder einen Datendienst (der dann ja einen Inhalt in der genannten Form – meist Text basiert – liefert) handelt. Im Folgenden soll eine einfache Erklärung ohne Anspruch auf Vollständigkeit und Exaktheit gegeben werden (denn das Thema ist doch sehr Facettenreich), denn Gründe für die Zugriffeinschränkung über (Sub-)Domänengrenzen hinweg gibt es viele:
Beispielsweise möchten Anbieter Ihre Dienste oder Inhalte nicht anderen frei zur Verfügung stellen. Ein anderer Grund sind Authentifizierungsprozesse, die nur von vertrauenswürdigen Stellen aus erlaubt sein sollen. Zurecht kommt nun jedoch der Hinweis, dass man dies ja einfach durch einen Proxy-Server umgehen kann, der diese Sicherheitseinstellungen ignoriert – also durch einen Server, der die Kommunikation mit der Domäne B durchführt und dem die Sicherheitsrichtlinien egal sind. Also warum dann der Aufwand, wenn sich das so einfach umgehen läßt? Ganz einfach: Diesen einen Server kann man relativ leicht erkennen und gegebenenfalls auch sperren. Was aber, wenn eine einfache SWF-Datei auf tausenden von Clients läuft, die über unterschiedliche Netzwerkanbieter und dynamische IP-Adressen kommen? Dann wäre eine Sperrung von großen Teilen des Internets mit weitreichenden Folgen für die Erreichbarkeit notwendig. Ein weiteres Beispiel sind DNS-Angriffe: Wenn also von Domain A auf Domain B so viele Anfragen ausgeführt werden, bis Domain B überlastet und somit nicht mehr erreichbar ist. Dies wäre vermutlich durch einen einzelnen Proxy ohnehin kaum zu leisten und selbst wenn, dann könnte der Server schnell erkannt und gesperrt werden. Aber tausende von Clients, die über unterschiedlichste Netzwerkadressen direkt auf die Domain B zugreifen, sind kaum alle zu sperren. Fazit: Gut, dass es Sicherheitsrichtlinien gibt und diese Art der “Angriffe” somit mit Flash, Java und Silverlight nicht möglich sein sollten…