The Web Protection Library – plans and processes.
First off let me introduce myself; my name is Barry Dorrans, I’m a recent transplant from the UK and I finally joined the Information Security tools team 6 weeks ago after the long and involved process of visa acquisition. Before joining Microsoft I was a consultant in the UK working with various companies on developer security issues, I was a Developer Security MVP and an active member of the UK .NET technical community, running a user group in Oxford and writing “Beginning ASP.NET Security” for Wrox Press.
One of the things that attracted me to the role was the tools the team produces and in particular the open source status of the Web Protection Library and so it’s with great pleasure I am taking on the development of WPL, along with Frank, the new PM for WPL and Randy Evans, my co-developer and Jessika the team’s tester. As part of the process we’re going to share more with you about what we’re doing, what we’re planning and hopefully give you a chance to engage with us as we plan development sprints, gather feature requirements and fix bugs.
We kicked off our first sprint on Monday 21st March, a sprint we’re describing as “fit and finish”. We’re spending a lot of time documenting the code and adding tests. We’re also addressing what has been a pain point for a lot of you – medium trust. The original AntiXSS library performed nothing but encoding and didn’t have any special requirements for hosting. When the first WPL beta was released we added HTML sanitization, which came from another team. Sanitization is rather computationally expensive and the code uses unsafe array manipulation in an effort to cut down the time it takes; however for obvious reasons a lot of shared hosters don’t allow unsafe code to run in their shared environments. With the next release of WPL we’re putting AntiXSS back into its own assembly and marking it with AllowPartiallyTrusterCallers so you won’t have to strong name your web assemblies to use it. This does mean if you want to use the HTML sanitization functions you’ll need to add a reference to the new assembly into your project.
One other change that will become obvious when we release the code is the move to VS2010. We’re doing this to provide support for ASP 4.0’s ability to switch out HTML encoding engine and we’ll be providing a pre-built class for this. In order to keep support those of you who are on .NET 2.0 - 3.5 this will be made available in yet another assembly or of course you simple take the class and add it into your own project.
It’s unlikely we’ll release the results of this sprint publically as this is these are the only functional changes we’re making and we’d like to wait till we to release under we have some actual bug fixes – but if you feel we should then leave us a comment!
Talking of bug fixes once this sprint has finished we’ll start going through the bug list and feature requests. In case you’re wondering bugs and features from the Connect programme make it into our internal systems automagically. We also had a lot of feedback at the MVP summit from the Developer Security MVPs which we’re planning to address. If you’ve added a bug onto the AntiXSS codeplex site then we manually triage those and bring them into our internal systems on a regular basis.
As we near the end of this sprint Frank will be sharing with you our priorities and tasks for the next sprint and I plan to start sharing our new Threat Models as we prepare them and any mistakes we’ve made with the threat modeling process – something I hope will enable everyone to learn how to model effectively.