Security considerations for intranet developer making public facing website?

Question

I have alot of experience writing internal Intranet applications, but very little when it comes to writing public facing web applications where it is likely that a certain percentage of people will try and be malicious.

The app is written with MVC.net, JQuery and Subsonic.

What steps can I take to project my application, to make it reasonably projected?

Iv done some things already:

• Form validation on the server and client side
• Enforcing password complexity
• Check in controller Actions that current user is ok to do the operation.

Have been quite paranoid about people looking at the html source of my forms and seeing what the form is posting, and using this to manually creat a form post with different values to do operations they shouldn't. Is this paranoia well founded do I need to do this on Actions attributed with the HttpVerb GET and POST or just GET?

Do I need to be worred about SQL injection with ORMs?

Answer 1

Check authorization on ALL controller actions, both GETs and POSTs. Authorize not for session, but for each request once again.

Server validation is a must. Also enforce some amount of data integrity on the database level. Fail as soon as you detect some exceptional situation. Don't try to recover and handle all possible scenarios to please the user.

Don't rely on user identification like username stored in cookies. It can be replaced. Add something more and unique to that. Cookies can also be stolen and transfered to another PC. Consider the option to check an IP address (for example) to get some assurance you are not tricked.

Limit user operation amount per time unit. Don't allow to make 100 submits in a minute.

All user inputs have to sanitized. Yes, worry about SQL injections.

Don't store passwords in plain text. Hash them. If someone breaks into your system, they can misuse the passwords by assuming the user has the same password to access his email account, banking system etc.

Another good idea could be not to use the public nickname, email or something else known publicly as a login name. Allow user to use a login to perform login operation, and a different name to represent them publicly on the site.

Actually, check out this thread. It has a good summary of that kind of knowledge.

What should a developer know before building a public web site?

Answer 2

• Account lockout (30 minutes) after a few failures to prevent brute forcing.
• Consider SSL as an option for the registration and login pages.
• An IsInRole function on your user class is an easy way to manage security of user actions.
• Use a token for any "Remember Me" feature. Make sure that the generation of this token is crypto secure.
• Only use parametrized queries, to prevent injection.
• Encrypt cookies.
• Microsoft Anti-XSS
• Be paranoid.

There are a lot of considerations. As always, this will be a work in progress.

Answer 3

Paranoia when building publicly facing sites is your friend.

Are your cookies encrypted? It's easy enough to accomplish through a custom HttpModule. This is on top of normal SSL.

Yes, you need to worry about sql injection. Not all ORMs are created equal. We recently found a sql injection problem under certain conditions with LINQ. Don't trust anything that writes your queries for you.

If this deals with sensitive information, add code to prevent replay attacks. Basically, assume everything that leaves your server will be captured by someone.

Answer 4

• All user input is to be treated as if it's going to destroy your server (XSS)
• All info coming to/from the database is the devil and must be clensed (SQL Injection)
• The cookie monster will get you if you aren't careful.
• Program as if Javascript is turned off but give features for those users who have it on

Answer 5

For an exhaustive catalog of web application vulnerabilities, solutions for the most significant, and development practices to help write more secure code, check out OWASP and CLASP.

Answer 6

• Sanitize any input the client sends you. POST/GET data might be the easiest to fake, but it's definitely not all.

• Don't depend on JavaScript alone for any security measures, since that can just as easily be bypassed.

• Make sure you have a secure policy for password recovery (e.g. not simply a "secret question")

• Have some kind of brute-force protection e.g. CAPTCHA

Answer 7

How serious are you about security ?

There is a RFC Standard for security considerations.

http://www.faqs.org/rfcs/rfc3552.html

Run through it (42 pages or there abouts). It contains most security considerations. When creating a new RFC you'll use this document to guide you through considerations.