Website Security - Help Me Suck Less

Question

I am a little behind in time when it comes to website security. I know the basics - I check all incoming data, storing data in db, use a salt for passwords, etc. But I feel that there is a lot that is missing, which can bite me in the butt. This is especially true of my slow migration to .NET. I'm just not sure how to replicate what I know in PHP in .NET. So, below are some of the things that I thought of, I'm sure I need help.

Problem: Session Security
PHP: Use session_regenerate_id () whenever the user does something important.
.NET: I do not know how to replicate this here.
General: What else am I missing?

Problem: XSS
PHP: Use htmlentities () to convert potentially dangerous code into something that can be done (basically) harmlessly.
.NET: I believe in MVC, using the <%:%> tags in a view does the same.
General: Is there anything else I can do to block JavaScript? How about a complete rejection of HTML? How to protect a text box?

Problem: remote execution
PHP: use regEx to find and remove calls to eval () functions.
.NET: no wonder I don't know.
General: Again, should I look for more?

Problem: directory traversal (possibly related to above)
I just don't know how I'm worried about this. I am also not sure how to block it.

Suggestions, links to articles (with code examples), etc. welcome, and will be very grateful.

Answer 1

session_regenerate_id

I do not think there is an equivalent. Sessions are short-lived, therefore, if an attacker entered the session on time, this should also happen after changing the access level.

Something extra is that sessions are not intended to authenticate a user in asp.net. When using user authentication, forms authentication is used.

It is said above that everything you do depends on the person in the medium attack. This is true for many sites, so cookie grabbing is a problem in everything.

When you do something special, ask the user to enter their password again / which must be done via https. If you need to perform a number of special operations, you can do it once, but from now on, requests / cookies should be sent via https. In this context, you can fix a cookie with a modified authentication form that provides access to special operations and requires https.

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

Yes, such an equivalent <% = Html.HtmlEncode (someString)%> / with something extra to prevent double coding (you should study this).

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

In .net you do not have such shorthand with such wide access. If you are clearly not doing anything unusual, you are most likely in order.

Directory traversal (possibly related to above)

Use MapPath and the like. This actually prevents going beyond the limits of the site folder. This suggests that you avoid getting paths at all, since you can still provide unintentional access to special files inside the asp.net folder. Actually, this is part of what happened to the Microsoft handler in the offensive scroll vulnerability there - more on my blog

You can add CSRF to the list.

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

insult attack:

Apply the work around and then the patch as soon as it comes out.

Find out about everything I mention here: asp.net padding oracle: how does this relate to getting web.config, faking cookies and reading other sensitive data . Understanding all of this is important, especially if you use any functions, that is, you don’t want anyone to put sensitive data into the viewing state :)

Answer 2

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