Alex Rivera | Logout

Security Concerns When Working With New Technologies

Asked 2009-06-04T15:36:28.433
17

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

.net asp.net asp.net-mvc security
Edit
Report

1 Answer

2

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.

answered 2009-08-12T08:31:55.823

Your Answer