Silverlight 4 Security Overview White Paper


[Update: This paper has been updated and published as the Silverlight Security Overview. -Nick]


Wanted to let folks know about a white paper we’re making available (attached below). We plan to incorporate this into the main Silverlight documentation by the time we ship the Silverlight 4, but in the meantime I didn’t want to keep this content to all ourselves.  J We have a fair amount of documentation on Silverlight security already, but there’s a couple holes that we hope to address with this paper. The more obvious is that it’s, well, an overview — sometimes you don’t need all the gory details, you need a basic lay of the land so you can orient yourself and figure out what details are relevant to you. The second thing we’re trying to address is to give an introduction to our security thinking, for example why it’s safe for Silverlight to allow sandboxed apps to open files (OpenFileDialog & isolated storage). We don’t get into every detail of every security decision we’ve made, but it will give you a lot of insight into how we choose what to enable in the sandbox.


As usual, we appreciate your feedback, both about Silverlight and about this paper, either via blog comments or by emailing me directly at nkramer@microsoft.com. Thanks.


Update 11/23 — Thanks for your feedback, I made some edits based on your suggestions:



  • reorganized the networking section

  • added WebBrowser.NavigateToString() as a way to create XSS holes in Silverlight

  • improved wording — “keep the user safe” -> “help keep the user safe”, got rid of the “provably correct” line, etc.

  • provided pointer to more info on mark of the web

  • fixed a couple typos

  • used .doc instead of .docx

Thanks again, I’m looking forward to the next round of feedback!


 

Silverlight security overview.doc


Comments (9)

  1. Luigi says:

    Thanks very usefull.

    Is the HTTP Basic authentication implemented on SL 4 ?

  2. Philip says:

    Nick,

    Could you please attach a doc version of the paper as well.

    Thank you in advance

  3. Nigel says:

    Hi

    Same question as above, is basic authentication implemented?

    Nigel

  4. Walter Wong says:

    Hi Nick,

    I think developers need to learn how to write secure code for SL3 as well. Since you already wrote the article about it on point #3, why not just told us which are also applicable fo SL3.

    from

    Walter (DevSec MVP)

  5. Hans says:

    Hi Nick,

    Will Silverlight ever get real serialization via reflection like full trust WPF apps has? I understand allowing reflection is a security issue but with the new "elevated trust" mode – why not allow it there?

    We have a very strict domain model today which requires serialization to work with fields only and this has been impossible in both SL and medium trust WPF apps.

    We want to be able to use our domain model in both the Silverlight app and the WCF server side and we cannot resort to using attributes only like RIA services suggests as this would seriously compromise the domain model of our entire architecture.

    Thanks,

    Hans

  6. Hello Nick,

    The document states that, under elevated trust, sockets are allowed without policy files (great). Is the port restriction gone too ?

    And is there any listening (tcp) sockets story coming up ?

    Thanks for sharing!

    Sebastien

  7. nkramer says:

    @Luigi — SL’s default networking stack, BrowserHttpWebRequest, leverages the browser to handle authentication, this works in SL3. SL 4 enables an application author to control authentication using ClientHttpWebRequest for authentication protocols such as NTLM, Basic and Digest.

    @Philip — new attachment is .doc

    @Walter — the bulk of this paper applies equally well to SL3, I’ve tried to call out everything that was specific to SL4 using the "SL4beta" tag.

    @Hans — I’m not sure about the serialization part, but Silverlight 4 supports a limited form of private reflection known as "restricted member access". Basically, you can reflect against private & internal methods, as long as they come from non-platform assemblies. Internals/privates in platform assemblies are still off-limits. (Here, platform assemblies means Silverlight Runtime — you can reflect against SDK assemblies)

    @Sebastian — in SL4 beta, trusted apps still have port restrictions around sockets, we are investigating lifting that limitation for the final version (trusted apps only).  We don’t currently have plans for listening TCP sockets in SL4.

    Thanks.

  8. Cain says:

    Yea, I second Sebastians request… having as much socket support as possible is critical in my opinion, and the arbitrary restrictions are pretty cramping