Security Concerns When Working With New Technologies

Question

Do you find that when you work with a new technology that you're never quite sure what security gaps your leaving in your code?

I've been working with ASP.Net Web Forms for about 5 years now and am fairly confident my code is at least secure enough to stop most known attacks. Looking back a lot of my early code I have unknowingly left gaps in a lot of the security areas especially query strings and viewstate but I feel over time I learnt what the vulnerabilities were and made sure I didn't make the same mistakes again.

However I've recently started a new project in ASP.Net MVC and I really have no idea what security holes I'm leaving open. This reason alone is almost putting me off going forth with this. I'm reading up on it like crazy at the minute but am sure I've not learnt nearly enough to make it as secure as I could with Web Forms. What do you guys do to make sure you don't leave yourself open to attack?

Edit : Starting Bounty as Curious to see if there are any more opinions

Answer 1

all the time.
the more you learn, the more you can prevent security holes in the future.

you said it yourself, your old code is ripe with security holes that you would never add to anything you write new. This is a great testament to your ability to learn and adapt to what you are working with.

I think you are on the right track with your thinking, remember, no one gets it right the first time (at least I don't) that's why re-factoring is so cool.

don't let this deter you from learning something new, just do your best, read up on security threats for your technology and go. (try http://www.securityfocus.com)

peer reviews can help with this and there are tools out there that can make finding security holes easier.

Answer 2

I guess do what we do whenever we learn something new like when you are a confident bike rider and switch to motorbikes you never take it on the freeway on day 1. In my exp prototyping helps a lot. Put your code to test by actually trying to break it. Reading up on the new technology is extremely important. I have seen people jump into new technologies just because it sounds cool.

Do a bit of research and find any OSS built on the same technology. Playing around with it may reveal a lot of things.

EDIT: ASP.NET MVC OSS ?? Look at the nerddinner.com source code and play with it. Contributors are top notch and I assume they must have given a thought to security while creating this!

Answer 3

I think a LOT of what you learned about with ASP.NET is transferable to ASP.NET MVC. It's still HTML (exploits: XSS) over HTTP (exploits: all input [cookies, URL parameters, form input, headers] can be forged, session hijacking, CSRF) with a database back end (exploits: SQL injection).

I would recommend Steve Sanderson's book on ASP.NET MVC titled Pro ASP.NET MVC Framework. It has an entire chapter dedicated to these topics.

Check out Chapter 13 'Security and Vulnerability' from the Table of Contents for the book.

Answer 4

The technologies you use may change, but the underlying problems of security don't. If anything, I would expect fewer security holes in code that uses newer libraries, because they're designed with common attacks in mind. For example, SQL injection just Doesn't Happen with the classes VS2008 generates via DBML.

Answer 5

This is a very difficult question with probably no great answer. However, there are a couple things you can do to increase the possibility of keeping yourself safe when using new technologies.

1. Keep the following in mind: there are three types of vulnerabilities. Ones that are unique to the framework you are using (e.g. Ruby on Rails public controller problems), ones that are unique to the type of application you building (e.g. Web Applications have to worry about XSS), and ones that are unique to your application in particular.
2. Identify how the new technology you are using mitigates application type security vulnerabilities. For example, how does ASP.Net MVC mitigate XSS? How does it mitigate SQL Injection? If there is no answer in the documentation, then figure out how you are going to address these common classes of vulnerabilities. Also, take pause because if the framework doesn't mitigate these issues then maybe the frameworks developers haven't prioritized security and may not have written a very robust framework.
3. Figure out why you need security and what you are trying to protect. For example: Does your application require authorization before viewing sensitive data? If so, determine what features the framework provides for authorization.
4. Look for a security section in the documentation. Often known issues are documented but people focus so much on getting their problem solved that they don't look for it.
5. Code defensively and be aware of how user input is used. Be generous in defining what is user input. For example, the querystring or post fields are obvious, but in many MVC frameworks the URL dictates what code runs (e.g. see Ruby Routes vulnerability). Be very aware of how the data is handled
6. Stress test your business logic and figure out how it could potentially be abused.

So in short: Handle user input carefully, read the existing documentation, determine what security you require, and figure out how the framework mitigates common vulnerability classes. Being aware that security is a priority and paying attention is 50% of the fight.

Answer 6

Tip specifically for ASP.NET MVC:

In your views, use the HtmlHelper methods as much as possible (e.g. Html.BeginForm, Html.TextBox, Html.ActionLink, etc), versus raw HTML tags. The helpers will automatically HTML encode the values you pass into it, reducing the chances of creating an XSS vulnerability.

For all other input that you are playing back in your view, always use Html.Encode.

Answer 7

Again, specific to ASP.NET MVC, really watch the use of Model Binding. You should always explicitly specify the properies that will be bound.

Failing to do this can lead to some unexpected side effects (as I found out..!) and may allow someone to maliciously alter model properties.

Answer 8

A lot of MVC is the same as WebForms - they both sit on Asp.net, as @GuyIncognito has already said, most of it is the same.

The main difference is that WebForms can validate their postback - they have unique keys in the page content that confirm that each postback has come from the page served.

Only it doesn't, it can be hacked, the viewstate wastes loads of space and it can never completely be turned off. I find best practice with WebForms is never to assume that the postback is definitely from the page served and re-check security anyway.

With MVC postbacks are to different actions, with models and model-binders encapsulating the content in type-safe objects. The checks still need to be done, as spoofing the postback is now much easier. So:

• Never assume that the model is from a particular source.
• Assume that the model may be corrupted and don't rely on it.
• Treat MVC controller actions as you would WebMethod or service calls - a hack attempt can call any of them, in any order, with any parameters.

All of this is best-practice in WebForms anyway, it's just easier to attempt this type of hack in MVC now.

MVC includes anti forgery token support, here's an excellent article on them. it helps, but I still wouldn't rely on it.

Everything else (encode all user generated output, parametrise all Sql input, etc) is the same.

Answer 9

Simple, never trust anything that comes in to your application :) Some people have already made some great posts here about the fact that you can fake any posts to the framework easily, but this should be no different from webforms anyway since it can be done.

ASP.NET MVC has some nice features for validating your data, especially with v2. Here's Scott Gu's post about v2 that shows how to do validation in a really neat way. Also note that you can easily implement your own validation methods in the same way.

Authorization is also the same, you can decorate your Controller or Action with the Authorize attribute and specify which roles are allowed to access it. This uses .NET's authentication framework just like web forms, so you can implement your own security here as well.

Overall I really find these(most) things much easier to work with in the MVC Framework as there is no magic going on behind the scenes. You can replace almost anything in the framework and you are in full control. It might require a little getting used to though if you have been working with webforms, but I'm sure you'll love it once you do.

Answer 10

One simple solution: Assume there are security holes in your application, and plug them up outside of your application. For example, restrict access (via IIS) to "unsafe" URLS with SSL and/or IP restrictions.