我正在寻找ASP.Net中最好的可重用库和内置功能，以防止OWASP排名前10位的安全漏洞，例如注入，XSS，CSRF等，以及易于使用的工具来检测这些漏洞，以供测试团队使用。

您认为什么时候是在开发生命周期中开始将安全编码合并到应用程序中的最佳时间？

我的经验是，仅仅给开发人员一个工具箱并期望最好的方法实际上并不能很好地工作。安全性是代码质量的一个方面。安全问题是错误。像所有错误一样，即使是更了解的开发人员也最终还是会编写它们。解决该问题的唯一方法是建立一个流程来捕获错误。

考虑一下您需要哪种安全流程。仅自动化测试？代码审查？手动黑匣子测试？设计文件审核？您将如何在错误跟踪系统中对安全问题进行分类？您将如何确定修复安全漏洞的优先级？您将为客户提供什么样的保证？

OWASP ASVS验证标准可以帮助您入门，它可以帮助您验证安全验证过程是否确实有效：http://code.google.com/p/owasp-asvs/wiki/ASVS

我的两分钱：

• 永远不要相信用户输入。这包括表格，Cookie，参数，请求...
• 保持库更新。我们中间每天都会出现安全漏洞。补丁已发布，但如果您不应用它们/升级库，它们将毫无价值。
• 限制性和偏执。如果您需要用户输入他的名字，请加以限制，让他仅使用[A-z]字符，依此类推。强大的约束会惹恼普通用户，但它将使您的系统更安全。
• 永远不要记录关键数据。这意味着您不应记录用户使用的密码(显而易见的密码)之类的内容，也不应试图记录用户未能登录系统时输入的密码(因为他可能输入错误)猜测)。您可以将此示例扩展到所有关键数据。请记住，如果它不存在，您不必担心有人试图获得它。

并摘自维基百科的CSFR文章：

• 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

最佳实践：编码时要注意这些漏洞。如果您编写代码，请考虑您在做什么。