Security Abstraction: How much is too much?
I was having a conversation the other morning with a colleague and we were discussing how much security an enterprise web application developer should be exposed to. This topic has come up in numerous conversations over the past year or so and it is still debatable. The question is how much abstraction should, or better yet can, be provided to developers? A few dev managers believe that security should be completely encapsulated and their developers should not have to waste their time with it.
The Microsoft .Net platform builds in a lot of security features. Each release adds more features that help developers create more secure applications. There are a few issues with expecting these features to fully protect your application with no extra thought. First, the built in features work best when best practices are followed. For example, using parameterized queries or server controls. Second, it is impossible for a framework to account for all ways a program can be written.
Even with security built-in, does that mean that developer’s don’t need to understand what these features are? Take the validateRequest feature for example. I have asked many developers what this feature does and very few were able to explain it. So why did I pick ValidateRequest as an example? First, not many developers seem to understand it, but more important is that they turn it off. In rapid application development practices it is common to not get rock solid requirements defining the inputs for every field. This may lead to poor input validation on the server and open the application up to Cross Site Scripting attacks. I can confirm that leaving validateRequest on does not provide 100% protection from cross site scripting, but it does provide an extra layer of security. Input validation is still required, but there is a small safety net to help out.
Cross site scripting is mostly focused on output encoding and the .Net framework is getting better at automatically encoding outputs for the server controls. This solution is not whole though. If input is not sanitized correctly then some controls may allow XSS to be set in them to be sent to the browser. What if the developer decides not to use server controls and instead uses Response.Write to send some content. It is common to see sections of the application built up with StringBuilder’s and then just flushed to the client. In this type of situation, it is difficult to build an efficient framework to handle security. I guess one would have to override the Response.Write method and have it parse all data looking for HTML attributes to encode and HTML text to encode to make the data safe. At this point, it does not seem that practical.
Developers have to understand security at a base line level due to the complex nature of programming. It is not ideal to believe that security can be built into all functionality and no thought goes into it. I think it is great that frameworks like the .Net framework build some security protection in, but the developer must be able to fill the coverage gap. It is determining that gap that is more important than trying to abstract security completely.
Comments
Follow Us
