Silverlight cross-origin socket

The http://msdn.microsoft.com/en-us/library/cc645032 (VS.95). aspx

Everything is temporary. Compared with beta1, beta2 has changed a lot and does not know whether it will change during official release.

The translation function is Memo.

Silverlight 2 beta supports two remote server access methods:

The WebClient and HTTP class in the System. Net namespace. These classes use HTTP or HTTPS for access.

The Socket class in the System. Net. Sockets namespace. These classes provide lower-level socket interfaces that can be used in more common network communication applications.

Both cases require a security mechanism to prevent the silverlight program from initiating unauthorized connections. Potential risks include:

DOS Attacks: a large number of remote PCs are used to attack a specific site.

DNS rewrite attack: Write the DNS of the affected site as the silverlight source site, so that silverlight can access non-source sites

Reverse connection attack: allows the user's silverlight to access a remote node, allowing the attacker to access the user's private network through this connection (this attack mode is that the user accesses a malicious silverlight site, download and run silverlight. This silverlight establishes a connection to the private network, for example, internal file server, to steal internal file server data)

In addition to preventing the above attacks, Silverlight also provides better administrator control.

In the original design, only silverlight is allowed to access the source site. This security model of beta1 only allows silverlight to access the downloaded site through socket. The source site can be localhost, if this silverlight is opened directly from the file.

Beta includes support for cross-origin connections to allow access to non-source sites. This important feature allows the silverlight program to use existing web Services. Before allowing a network connection, Silverlight 2 Runtime needs to download a security policy file from the website. This security policy file only affects cross-domain network access between WebClient and HTTP. The WebClient and HTTP class do not need security policy files when accessing the source.

For socket, this security policy system not only affects cross-origin access, but also the source access. Even source access requires a security policy. This is different from beta1. In beta1, Source Access is always allowed.

Security Policy System Basics

Silverlight has two security policy files:

Flash policy file-crossdomain. xml file used by Adobe Flash. This policy file is only used for WebClient and HTTP classes.

Silverlight policy file-can be used in Web/Socket. This file and the Flash policy file have different formats.

Before a connection to a network resource is allowed, Silverlight2 Runtime tries to download a security policy file from the network resource. Different access methods have different download methods.

If the connection is WEB cross-origin, Silverlight2 uses the HTTP protocol to download the security policy file. When Silverlight2 is running, it first tries to download the Silverlight policy file clientaccesspolicy from the root of the target domain. xml. If you can obtain this file (even if an error occurs during File Parsing), it uses this file as a cross-domain policy file. If the file cannot be found, the Silverlight runtime tries to download the flash policy file crossdomain. xml from the root of the target domain. The flash policy file must be accessible to all domains.

If it is a socket connection (cross-origin or source access), silverlight2 tries to connect to port 943 (fixed port) of the target site during runtime ). If it can be created, a special <policy-file-request> string is sent to the server during the Silverlight operation to obtain the policy file. When silverlight2 is running, it waits for the target site to return the Silverlight policy file. If a policy is returned (even if a parsing error occurs), the policy file is used.

If the policy file is correctly parsed and the permission is ensured, the connection is established. Otherwise, the connection and subsequent connections are blocked.

Another restriction on socket connection is that the server port must be within ipv2-4534. If the port of the server provided by the server is not in it, you can use program redirection (such as SSH)

Deploy a security policy file for WebClient/HTTP. The system administrator must configure web service to download the policy file.

To deploy the security policy file for the socket, the system administrator needs to configure a separate authentication service.

The following is an open socket 4502 ~ The policy file of port 4506. Listen must be on port 943. (This problem is depressing. How can this binding conflict be solved ?)

<?xml version="1.0" encoding ="utf-8"?><access-policy>  <cross-domain-access>    <policy>      <allow-from>        <domain uri="*" />      </allow-from>      <grant-to>        <socket-resource port="4502-4506" protocol="tcp" />      </grant-to>    </policy>  </cross-domain-access></access-policy>

If 943 is bind, kill the process, start your server, and allow all the policy files.