Alsalam alikom wa ra7mat Allah wa barakatoh (aka Peace Upon You)

I’m planning to start a series of posts, targeting SharePoint developers, introducing some parts of features I got exposed to. I’ll start this by talking about new features we are releasing as part of our security solution in Windows Sharepoint Foundation 2010.

One of the famous threats in the internet is XSS (Cross Site Scripting [Wikipedia link]). Let me describe it in a short scenario,
BadUser creates a page with a form and some javascript code that posts the form data to BadSite.com, then BadUser uploads that page into GoodSite.com/userPages, now he also got access to whatever information that site provides about its users.
GoodUser browses to the page in GoodSite.com, fills the form and violla, BadUser gets the information + whatever his script can gather about GoodUser..
The problem here is that GoodUser didn’t really know that this page will go post data somewhere else… and has no way to know except by using some advanced techniques…

This can be applied on WebParts, some WebParts allow users to directly inject nonencoded text that gets rendered into WebPart Pages (WikiPages).. eg. ContentEditorWebPart. For this, we have introduced new web.config flag called SafeAgainstScript. which basically if set to false, will prevent non-privileged users from changing properties that might not be encoded.

And into the details…

We, generally, prevent contributors from modifying unsafe properties in WebParts. For that to be flexible, we introduce 2 new flags

• SafeAgainstScript SafeControls [MSDN Link] flag, setting this flag to false (it’s false by default) on any SafeControl entry, means contributors are not allowed to insert these WebParts into WebPart Pages / Wiki Pages, and if a Designer (a user with Add and Customize Pages permission [MSND Link]) has already added that, then contributors won’t be allowed to modify any of its properties except for the Title.
• e.g

<SafeControls> 
         <SafeControl Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXX" 
Namespace="Microsoft.SharePoint.WebPartPages" TypeName="TitleBarWebPart" Safe="True" AllowRemoteDesigner="True" SafeAgainstScript="True" /> 
</SafeControls>

• RequiresDesignerPermission property-level attribute. It comes in effect only when a WebPart is marked as SafeAgainstScript=True in Web.Config SafeControls entries, WebPart developers can use it to say “even though this WebPart is safe, these specific properties are not”
• e.g

[RequiresDesignerPermission] 
public string Content 
{ 
    get { return _content; } 
    set { _content = value; } 
} 

• Here is a matrix that explains which flag will have the upper hand in different situations:
  • SafeAgainstScript=False

    	Contributors	Designers & higher
    RequiresDesignerPermission=True	No Access	Can Access
    RequiresDesignerPermission=False	No Access	Can Access

    
    
  • SafeAgainstScript=True

    	Contributors	Designers & higher
    RequiresDesignerPermision=True	Can Access	Can Access
    RequiresDesignerPermission=False	No Access	Can Access

• For the built-in WebParts, we have taken the effort to hide the properties from the toolpane in situations where users have No Access to modify them. For custom WebParts, developers have two choices
  1. Use our built in ToolPane provider, and we will take care of hiding and showing these properties.
  2. If you need to provide a custom ToolPane, you will need to take care of that. (I understand we need to improve at this point to provide you with the public APIs to make your life easier)

I’ll put together a sample custom WebPart that demonstrate these new flags, and will update this post once I get it uploaded.

Stay Tuned!