保证应用程序的安全应当从编写第一行代码的时候开始做起，原因很简单，随着应用规模的发展，修补安全漏洞所需的代价也随之快速增长。根据IBM的系统科学协会(Systems Sciences Institute)的研究，如果等到软件部署之后再来修补缺陷，其代价相当于开发期间检测和消除缺陷的15倍。
为了用最小的代价保障应用程序的安全，在代码本身的安全性、抗御攻击的能力等方面，开发者应当担负更多的责任。然而，要从开发的最初阶段保障程序的安全性，必须具有相应的技能和工具，而真正掌握这些技能和工具的开发者并不是很多。虽然学写安全的代码是一个复杂的过程，最好在大学、内部培训会、行业会议上完成，但只要掌握了下面五种常见的ASP.NET应用安全缺陷以及推荐的修正方案，就能够领先一步，将不可或缺的安全因素融入到应用的出生之时。
一、不能盲目相信用户输入
在Web应用开发中，开发者最大的失误往往是无条件地信任用户输入，假定用户(即使是恶意用户)总是受到浏览器的限制，总是通过浏览器和服务器交互，从而打开了攻击Web应用的大门。实际上，黑客们攻击和操作Web网站的工具很多，根本不必局限于浏览器，从最低级的字符模式的原始界面(例如telnet)，到CGI脚本扫描器、Web代理、Web应用扫描器，恶意用户可能采用的攻击模式和手段很多。
因此，只有严密地验证用户输入的合法性，才能有效地抵抗黑客的攻击。应用程序可以用多种方法(甚至是验证范围重叠的方法)执行验证，例如，在认可用户输入之前执行验证，确保用户输入只包含合法的字符，而且所有输入域的内容长度都没有超过范围(以防范可能出现的缓冲区溢出攻击)，在此基础上再执行其他验证，确保用户输入的数据不仅合法，而且合理。必要时不仅可以采取强制性的长度限制策略，而且还可以对输入内容按照明确定义的特征集执行验证。下面几点建议将帮助你正确验证用户输入数据：
⑴ 始终对所有的用户输入执行验证，且验证必须在一个可靠的平台上进行，应当在应用的多个层上进行。
⑵ 除了输入、输出功能必需的数据之外，不要允许其他任何内容。
⑶ 设立“信任代码基地”，允许数据进入信任环境之前执行彻底的验证。
⑷ 登录数据之前先检查数据类型。
⑸ 详尽地定义每一种数据格式，例如缓冲区长度、整数类型等。
⑹ 严格定义合法的用户请求，拒绝所有其他请求。
⑺ 测试数据是否满足合法的条件，而不是测试不合法的条件。这是因为数据不合法的情况很多，难以详尽列举。
二、五种常见的ASP.NET安全缺陷
下面给出了五个例子，阐述如何按照上述建议增强应用程序的安全性。这些例子示范了代码中可能出现的缺陷，以及它们带来的安全风险、如何改写最少的代码来有效地降低攻击风险。
1 、篡改参数
◎ 使用ASP.NET域验证器
盲目信任用户输入是保障Web应用安全的第一敌人。用户输入的主要来源是HTML表单中提交的参数，如果不能严格地验证这些参数的合法性，就有可能危及服务器的安全。
下面的C#代码查询后端SQL Server数据库，假设user和password变量的值直接取自用户输入：
SqlDataAdapter my_query = new SqlDataAdapter(
"SELECT * FROM accounts WHERE acc_user='" + user + "' AND acc_password='" + password, the_connection);
从表面上看，这几行代码毫无问题，实际上却可能引来SQL注入式攻击。攻击者只要在user输入域中输入“OR 1=1”，就可以顺利登录系统，或者只要在查询之后加上适当的调用，就可以执行任意Shell命令：
'; EXEC master..xp_cmdshell(Oshell command here')--
■ 风险分析
在编写这几行代码时，开发者无意之中作出了这样的假定：用户的输入内容只包含“正常的”数据——合乎人们通常习惯的用户名字、密码，但不会包含引号之类的特殊字符，这正是SQL注入式攻击能够得逞的根本原因。黑客们可以借助一些具有特殊含义的字符改变查询的本意，进而调用任意函数或过程。
■ 解决方案
域验证器是一种让ASP.NET开发者对域的值实施限制的机制，例如，限制用户输入的域值必须匹配特定的表达式。
要防止上述攻击行为得逞，第一种办法是禁止引号之类的特殊字符输入，第二种办法更严格，即限定输入域的内容必须属于某个合法字符的集合，例如“[a-zA-Z0-9]*”。
2、 篡改参数之二
◎ 避免验证操作的漏洞
然而，仅仅为每个输入域引入验证器还不能防范所有通过修改参数实施的攻击。在执行数值范围检查之时，还要指定正确的数据类型。
也就是说，在使用ASP.NET的范围检查控件时，应当根据输入域要求的数据类型指定适当的Type属性，因为Type的默认值是String。
