views:

306

answers:

7

As a relative newcomer to both web and MVC, I am looking for a good summary of security best practices that I should implement.

The site will be public facing with "moderately sensitive data" (meaning we can't get sued, but probably wouldn't make many friends if the data got out!) and will have the following security steps taken: a: Forms/membership authentication and authorization b: Parameterized queries to prevent sql injection. c: Automatic timeout with x min of inactivity c: SSL for client to server encryption

What else do you recommend?

*Securing IIS and the network don't fall under my domain, so I'm more interested in the things I need to do to the software.

+3  A: 
  • If you are using cookies to recognize users, be sure to use an arbitrary token (such as a GUID) to store on the client for identification. I've seen too many websites that store my email address or username in my cookie... just have to change it to another!

  • Write your software so that it can run under medium trust.

Rex M
1st comment is so obvious and easy it is brilliant! Never would have thought of it in a 100 years :)Medium definitely applies and I will do. Thanks!
Aaron
Feel free to upvote the answer if you find it helpful. Maybe even accept it if it ends up being the best.
Rex M
+3  A: 

If you are new to web development you should be aware of cross site scripting (XSS). You can use Http.Encode helper method to protect against this in ASP.NET MVC.

Joel Cunningham
+1  A: 

Take a look at this post by Phil Haack- one of the MS dev’s involved in the development.

Additionally take a look at Microsoft Anti-Cross Site Scripting Library to filter out all incoming parameters

Cherian
+1  A: 
  1. Maybe you should choose methods that can be invoke from outside or not. For example be careful make a method like delete any tables like http://yourhost.com/edit/deletealltable. Make sure you design your class and methods well. And give attributes [NonAction] for preventing public method being invoke.

  2. Make sure you display data (especially sensitive) as you need with minimum fancy design and use client script as long as needed.

  3. Remove any unused trash files like unused files in your solution folder.

  4. Check and double check and validate any input control like textbox. I just can give something in the textbox to hack your system.
  5. If you use mix between MVC and regular ASP.NET, please remove any dependency between them.
nickotech2000
Could you explain removing the dependency between the mvc and regular webform? I'm not sure what you mean exactly. Thanks!
Aaron
for example, a regular aspx will display a fancy controls and then get data from mvc http://yourhost/customer/getall and render the result using javascript. It is ok, but you have more maintenance code in both
nickotech2000
A: 

Be sure you cover the basics thoroughly, independently of ASP.NET. Make sure your DBMS has a separate user with the minimal required privileges (e.g., CRUD and executing sprocs from specified databases) set up to access the database from the web application. Parameterizing queries is an excellent idea, but ALWAYS SCRUB YOUR INPUT ANYWAY: it is not a complete defense against sql injection.

Keep your design clean and easy to understand. Document whatever you do clearly, especially on the database side. It would be very bad if all your good work were destroyed by two programmers months or years later--one who didn't realize, say, that the database user for the web application (now accessing a database on a different server) shouldn't have root privileges, and another who added a control that didn't cleanse input properly. There's only so much that can be done about this sort of thing, but designing for the possibility that fools will be maintaining your code isn't so that coders will think you're sweet--it's so that fools won't put you out of business.

Adam
+2  A: 

Make sure you prevent out of order requests. Ensure client is authenticated before allowing to see sensitive data, or in some cases, make sure the client has come through the correct channel, before allowing a data manipulation. For example, only allow adding an item to your cart if the request came from the product details page. If you don't check, any one can mess around with the action. The URL would be like http://server/cart/add/XYZ123 and anyone could just tweak the 'id' parameter.

Greg Ogle
I'm a little embarrassed to ask know it is easy...but how do I get the name of the requesting page (to ensure coming from proper channel)? Is that part of the request object? Thanks!
Aaron
You can use a cookie/session variable to identify the entity with which you are working. Then only allow the action on that entity. You "previous" would set that, signifying you've already been there.
Greg Ogle