Locking Down Custom SharePoint Assemblies
Regardless of its a WebPart, or a client application that is going to integrate with SharePoint, for the love of all that is great and holy, lock down your custom developed assemblies, and don’t blindly give permission to things that probably shouldn’t have elevated permission sets.
The best way to do this is to start from scratch, and pretty much work your way up. So, you want to begin with this:
- [assembly: PermissionSet(SecurityAction.RequestOptional, Name="Execution")]
Then, build up your assemblies with the relevant permission sets. You will have to use RequestOptional in this example as using RequestMinimal will not have the appropriate effect that we are looking to achieve.
Whatever you specify in the “Execution” Permmision set will obviously take effect here. Then you can just use RequestOptional following to include any permissions you need.
Let’s take a brief example of where this might be a good idea.
Let’s say you have a helper method that is meant to read a file, and using a string builder, build that file into a string (I know, this is pretty simple, but it is for an example). For example, I use this below method to work with my SharePoint template names in my current environment for reporting:
- public string pushFileIntoString(string filePath)
- FileStream stream = new FileStream(filePath, FileMode.Open, FileAccess.Read);
- StringBuilder builder = new StringBuilder(100);
- byte buffer = new byte[0x400];
- for (int i = stream.Read(buffer, 0, buffer.Length); i > 0; i = stream.Read(buffer, 0, buffer.Length))
- builder.Append(Encoding.UTF8.GetString(buffer, 0, i));
- return builder.ToString();
This would of course be using some File I/O operations. Therefore, you would have to add:
- [assembly: FileIOPermission(SecurityAction.RequestOptional, Name="Execution")]
And then just work your way through. Writing secure code is important, more important than functionality, so take it into consideration while you are doing your development.