A cross-domain security consideration for Silverlight

See Silverlight in the documentation for the design of a lot of network security considerations. But because I do not particularly understand the security aspect, so it is very vague. Recently and colleagues Huang discussed some of these points, get some conclusions, and share with you.

There is a passage in the document:

There are important security considerations before your allow Silverlight clients to access WEB services in a Cross-domain situation. Whenever a cross-domain policy file in place for your should configure your Web server hosting the Web services to DISA BLE browser caching. This enables your to easily update the file or restrict access to your WEB services if necessary. Once the Cross-domain policy file is checked, it remains in effect for the browser sessions so the impact of The end-user is minimal.

In addition, the all Silverlight requests are sent with cookies and authentication. This means so if you are have WEB services that allow the users to access private information, and you should host such in a differ ENT domain than the WEB services exposed to third-party callers. For example, your have a Web store hosted at Http://www.tailspintoys.com. Your site allows customers to store billing information This includes credit card numbers. You are should not expose a WEB service which returns product inventory to Third-party Silverlight clients in the same domain. Because cookies and authentication are sent with each message, if your host this WEB services on the same domain, you have Effectively given the Third-party callers access to your customer ' s private billing information. In this example, your publicly exposed WEB services could safely is hosted at http://services.tailspintoys.com, because th Is is a different domain. Must carefully consider who you have exposed Web services to, and what otheR Web Services are located at this domain. Also, you should always keep your cross-domain policy file as restrictive as possible. For more information about exposing secure WEB services, the considerations for Service Access and making a servi Ce Available across Domain boundaries.

I made a simple translation of the second paragraph:

All SL requests Send cookies and authentication information along with them. This means that if you have a Web service that allows users to access privacy information, you should place the Web service under other domains and separate the domain names of Web services exposed to Third-party callers. For example, if you have an online shop placed in http://www.tailspintoys.com, your shop allows customers to store information about the transaction, which contains the credit card number. Then you should not put a Web service that returns a product list under the same host domain and then expose it to a third party's SL client. Because cookies and authentication information are sent along with the request, if you place these Web services under the same domain, you give a third party caller a convenient way to access your customer's private transaction information. In this example, the Web service you expose to a third party should be placed in http://services.tailspintoys.com. Because this is a different host domain. You must be very careful to choose which services are exposed and which services should be deployed under that domain.

We know that there is a property of a host name in the cookie, and that the browser will send the cookie only for requests to the same host domain. SL is no exception.

Let's say it's a scenario where Taobao opens up a Web service and we don't care what this service does. But we know that if you want your Web service to be invoked by other third party clients, you must place a specific XML file under the site, which we call the security policy configuration file, Flash corresponds to the crossdomain.xml file, Silverlight has a set of policy configurations in addition to the policy file that supports Flash, and is placed in the ClientAccessPolicy.xml file. Unlike Flash, SL will only look for this policy file from the root directory of the site, meaning that even if your Web service is placed in the/serivce/directory, the SL client will also look for "hostname/clientaccesspolicy.xml" Whether or not this file exists (I don't know why I'm designing it this way). So in order for his Web service to be Silverlight supported, Taobao must place a policy file in the root directory of the Web site.

If a customer buys something on Taobao www.taobao.com, the logged in session verification information may be stored in a cookie, and then the customer visits a malicious website (www.eyi.com of course the domain name is not so weak ^ ^), this malicious website will Amoy PO sends some HTTP requests for login. Because this is a cross-domain request, Silverlight runtime will go to the site root directory to find out if there is a policy file that has (and is validated by the access rights defined in the file) that the request is allowed, At the same time will you in the www.taobao.com cookies also sent to the Taobao system there, then this time, this malicious site is not in your knowledge of the situation to login to Taobao backstage, then he can perform some you do not expect the operation.

Of course, whether this example can be work is debatable, the only thing I want to tell you is that you have to be very careful about configuring access to the policy security files, exposing them to third party Web services (which involve cross-domain policy security), preferably in an isolated domain, which reduces security risk.

Do not know that I understand there is no problem, if not correct, please correct me ~