Website security - help me suck less

Question

I'm a bit behind the times when it comes to website security. I know the basics - validate all incoming data, escape data being saved to the db, use a salt for passwords, etc. But I feel like there's a lot I'm missing that can bite me in the butt. This is especially true with my slow migration to .NET. I'm just not sure how to replicate what I know in PHP in .NET. So, below are some things I've been thinking about that I'm sure I need help with.

Problem: Securing sessions
PHP: Use session_regenerate_id() whenever a user does something important.
.NET: No idea how to replicate that here.
General: What else am I missing?

Problem: XSS
PHP: Use htmlentities() to convert potentially dangerous code into something that can be rendered (mostly) harmlessly.
.NET: I believe in MVC, using <%: %> tags in a view does the same thing.
General: Is there more I can do to block JavaScript? What about denying HTML entirely? How would one secure a textarea?

Problem: Remote Execution
PHP: Use regEx to find and remove eval() function calls.
.NET: Unsurprisingly, no idea.
General: Again, is there more I should look for?

Problem: Directory Traversal (probably related to the above)
I'm just not sure how worried I should be about this. Nor am I sure how to block it.

Suggestions, links to articles (with code examples), etc. are most welcome, and would be greatly appreciated.

Answer 1

You can add CSRF to the list. They tend to be prevented by adding a hidden token in the form of your application, possibly matching a cookie, and then checking they both match when processing the form data submitted.

Answer 2

session_regenerate_id

I don't think there is an equivalent. Sessions are short lived, so if the attacker will get into the session in time, that should also happen after you change the access level.

Something additional is that sessions aren't meant to authenticate the user in asp.net. When using custom authentication you use Forms Authentication.

Above said, anything you do is subject to a man in the middle attack. This is the case for lots of sites, so cookie hijacking is a problem all around.

When doing anything special, require the user to enter their password again / which should be done over https. If you need to do a series of special operations, you can do that once but from then on requests/cookies need to be sent over https. In this context, you could emit a modified forms authentication cookie, that allows access to the special operations and has require https on.

I believe in MVC, using <%: %> tags in a view does the same thing.

Yes, that's kind of the equivalent to <%= Html.HtmlEncode(someString) %> / with something extra to prevent double encoding (should look into that).

Use regEx to find and remove eval() function calls.

In .net you don't have such a shorthand with so broad access. If you are not explicitly doing anything out of the ordinary, you are likely ok.

Directory Traversal (probably related to the above)

Use MapPath and similar. It actually prevents going outside of the site folder. This said, avoid receiving paths altogether, as you can still give unintended access to special files inside the asp.net folder. In fact, this is part of what happened to a Microsoft handler in the padding oracle vulnerability out there - more on my blog

You can add CSRF to the list.

Use the anti forgery token: http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

padding oracle attack:

Apply the work arounds & then the patch as soon as its out.

Learn about all that I mention here: asp.net padding oracle: how it relates to getting the web.config, forging authentication cookies and reading other sensitive data. Understanding all that's in there is important, specially if you use any of the features i.e. you don't want to be the one putting sensitive data in the view state :)