Best libraries/practices to prevent OWASP Top 10 Vulnerabilities

Question

I'm looking for the best reusable libraries and inbuilt features in ASP.Net to prevent the OWASP top 10 security vulnerabilities like injection, XSS, CSRF etc., and also easy to use tools for detecting these vulnerabilities for use by the testing team.

When do you think is the best time to start incorporating the security coding into the application during the development life cycle?

Answer 1

First best practice: Be aware of the vulnerabilities while coding. If you code think about what your are doing.

Answer 2

My two cents:

• Never ever trust user input. This include forms, cookies, parameters, requests...
• Keep your libraries updated. Everyday security flaws arise among us. Patches are released, but they are worthless if you don't apply them / upgrade your libraries.
• Be restrictive and paranoid. If you need the user to write his name, be restrictive and let him only use [A-z] characters and so on. Strong constraints will annoy the average user, but it will make your system more secure.
• Never log critical data. This means that you should not log things such as what password a user used (obvious) but also you should not be tempted to log what password did a user typed when he failed to log in into the system (because he may had a typo easy to guess). You can extend this example to all critical data. Remember, if it's not there, you don't have to worry about someone trying to get it.

And extracted from wikipedia's CSFR article:

• Requiring authentication in GET and POST parameters, not only cookies;
• Checking the HTTP Referer header;
• Ensuring there's no crossdomain.xml file granting unintended access to Flash movies[14]
• Limiting the lifetime of authentication cookies
• When processing a POST, disregard URL parameters if you know they should come from a form
• Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site can't put the right token in its submissions

Answer 3

My experience is that just giving the developers a toolbox and hoping for the best doesn't actually work all that well. Security is an aspect of code quality. Security issues are bugs. Like all bugs, even developers that know better will end up writing them anyway. The only way to solve that is to have a process in place to catch the bugs.

Think about what sort of security process you need. Automated testing only? Code review? Manual black-box testing? Design document review? How will you classify security issues in your bug tracking system? How will you determine priority to fix security bugs? What sort of guarantees will you be able to give to customers?

Something that may help you get started is the OWASP ASVS verification standard, which helps you verify that your security verification process actually works: http://code.google.com/p/owasp-asvs/wiki/ASVS