A Sneak Peak at the Security Runtime Engine
RV here again...
Traditionally security fixes are applied to specific pieces of code where a vulnerability exists which usually involves some development and testing effort. Imagine a system where an application is instantly secured by simple configuration. I am specifically talking about ASP.NET applications where Cross site scripting and SQL injection are some of the most common vulnerabilities found. This is exactly what the Security Runtime Engine (SRE) does, allows you to instantly turn on and protect applications which are already developed and deployed. This is very important for legacy applications which are already developed and usually don't have resources for any new development.
We have been working on a runtime engine specially for ASP.NET applications which could provide blanket protection to some of the common web application vulnerabilities. When I say blanket protection I mean single point of deployment and protection for the entire application. Thus we designed the SRE as an HTTP module which works at the IIS/ASP.NET layer providing protection against certain attacks. This is different from a web application firewall, it hooks the CLR and so doesn't operate on network protocol stream as it passes the network. As such it's tightly coupled to the application; an important and significant difference. Currently it provides protection against Cross Site Scripting by automatically encoding the controls.
It does this by walking the controls in the requested page and automatically encoding data in specific properties for example Label.Text. It can be customized to walk and encode (override) only specific controls such as Label, HyperLink, CheckBox etc. and additionally the type of encoding used can also specified for each individual property of a control. This customization enabled using a configuration file in the web root. SRE leverages the upcoming Anti-XSS library to ensure ultimate XSS protection.
Apart from simple encoding, SRE also contains some advanced features for better usability and adoption. Notably the following 3 features standout;
- Double Encoding Protection
- Encode Derived Controls
- Suppressions
The double encoding protection feature ensures that there is no double encoding possibility. Double encoding problem occurs if you encode data twice. SRE would make sure that it's encoding does not double encode the data. The encoding derived controls feature allows the derived controls to be automatically encoded if the base controls are already configured, for example if you create your own label control using the System.Web.UI.WebControls.Label then you control will automatically be secured without any additional configuration. The suppressions feature allows you to suppress encoding for specific pages or controls. If you want to encode programmatically or your page does not use any input, you could suppress encoding in that page. Ultimate flexibility! This can be done by adding the specific page path to the configuration file. Note that SRE encoding performance is similar to Anti-XSS library. We have had the ACE Performance testing team do an analysis and it runs at near native speed. We will be shipping both tools wit a performance test and a test harness. So enabling SRE is similar to implementing AntiXSS library but with added bonus of not having to implement any code changes and yet get protection across the entire application. You can think of it as the ability to have secure encoding out of the box. Of course this will break many existing applications which is one reason why the .NET framework couldn't implement this by default.
SRE also includes a configuration utility which reflects on the compiled ASP.NET application binary and creates a custom configuration file based on the controls in the binary. The configuration utility includes a master file which contains the list of all the controls, their properties and encoding type needed. This custom configuration file is very useful in making sure the proper configuration is applied to the web application.
In future SRE could be able to provide protection against certain other classes of web application attacks (in fact we already have work happening on that). SRE is code complete and in the final stages of testing. We will have an internal beta soon and a public one within the next few months.
Check our blog for the beta announcement!
Thanks
Anil RV