Udostępnij za pośrednictwem

  • Artykuł

Additional Security Considerations for Service Access

Microsoft Silverlight will reach end of support after October 2021. Learn more.

This topic outlines security considerations when using Silverlight version 4 with Web services.

Protecting the Silverlight Client and User Data

To protect your Silverlight client application against malicious services, you must be aware of several possible security issues:

  • A remote service might be able to send responses that cause the Silverlight client and possibly the user’s browser to hang or crash. This is possible with any data format including XML, JSON, RSS, Atom, and SOAP. Consider taking the following precautions:

    • Avoid initiating communications with an untrusted service when a crash or hang causes the user to lose data in your application. For example, save the user’s work to local storage before initiating such communications.

    • Avoid initiating communications with an untrusted service automatically, without an explicit user choice. This might lead to your application being unusable. Keep in mind that a malicious service might not always return malicious data. As an example, consider a scenario in which you are writing an RSS reader in Silverlight. The user subscribes to an RSS feed from an untrusted service, and you store the subscription information in local storage and automatically retrieve the feed every time your application starts. At some point, the service starts returning a malicious feed designed to hang the browser. From that point on, your application is inaccessible because it hangs on startup.

  • To prevent spoofing and information disclosure, use HTTPS to access services, especially when sensitive data is being transferred.

Protecting the Service

Keep in mind that services you expose for Silverlight clients can be accessed by anyone and used in ways you might not expect. Consider taking the following precautions:

  • Design your services to be secure in a way that is independent of the client code. For example, if you have an AddPayment(int amount) method on your service that must use a positive amount, do not rely on the fact that your Silverlight application might never send negative amounts. Perform the required check on the server.

  • Do not expose any more data from your services than you are comfortable exposing to the world. For example, if you have a Silverlight-based electronic book reader application that uses a GetPage(int bookId, int pageNumber) method, it is trivial for someone to write a loop that downloads your entire library of books in one batch, unless you put some throttling logic into your service.

  • Be sure to use the appropriate user authentication techniques. For example, a GetMail(int userId) method is not secure if it allows any user’s mail to be read just by passing a different user ID. A better solution is to expose a GetMail() method that looks at the current user authentication context (HTTP Auth, cookies, and so on.) and determines who the current user is based on this context.

When exposing a service for cross-domain access, as described in Making a Service Available Across Domain Boundaries, observe the following precautions:

  • In cross-domain-enabled services, do not rely on anything outside of the message body itself to authenticate the caller. In particular, do not rely on network topology (Internet/intranet zone distinction), IP address restrictions, cookies, or authenticated HTTP sessions. Relying on data passed as part of the request URL is allowed. For example, suppose a cross-domain-enabled photo sharing service that requires user authentication is accessed using http://api.contoso.com/PhotoService/GetPhoto. The service should not rely on cookies to authenticate the user. However, an authentication scheme could be used where a user authentication token is passed as part of the message or the URL - for example, http://api.contoso.com/PhotoService/GetPhoto?userToken=XYZXYZ.

  • Separate your cross-domain-enabled services from your regular Web pages and non-cross-domain-enabled services. It is best to do this separation by domain or sub-domain, but when using the Silverlight policy file (the clientaccesspolicy.xml file, not crossdomain.xml file) it is possible to do the separation by URL space. For example, http://photos.contoso.com might be a photo-sharing Web site with Web pages that use cross-domain authentication mechanisms that are unsafe, such as cookies. To add services that are safe for cross-domain access, add them to a separate sub-domain like http://api.photos.contoso.com. Then http://photos.contoso.com/clientaccesspolicy.xml should not exist, but http://api.photos.contoso.com/clientaccesspolicy.xml should exist and should enable cross-domain access.