如何提高asp.net安全性？

ASP.NET常见安全问题

一、SQL语句漏洞

许多程序员在用sql语句进行用户密码验证时是通过一个类似这样的语句来实现的：

Sql="Select * from 用户表 where 姓名 = '" + name + "' and 密码 = '" + password + "'"

通过分析可以发现，上述语句存在着致命的漏洞。当我们在用户名称中输入下面的字符串时：test' or '1' = '1，然后口令随便输入，我们设为aaa。变量代换后，sql语句就变成了下面的字符串：

Sql="Select * from 用户表 where 姓名='test' or '1' = '1' and 密码 = 'aaa'

我们都知道select语句在判断查询条件时，遇到或（or） *** 作就会忽略下面的与（and） *** 作，而在上面的语句中1=1的值永远为true，这意味着无论在密码中输入什么值，均能通过上述的密码验证！

Select * from 用户表 where 姓名 = '合法的姓名' or '1' = '1' and 密码 = '' //无需密码

Select * from 用户表 where 姓名 = '' or '1'='1' and 密码 = '' or '1'='1' //无需用户名和密码

Select * from 用户表 where 姓名 = '合法的姓名' --' and 密码 = '' //无需密码

解决方法：

防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行：

1、检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。

2、对于动态构造SQL查询的场合，可以使用下面的技术：

第一：替换单引号，即把所有单独出现的单引号改成两个单引号。

第二：删除用户输入内容中的所有连字符。

第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除 *** 作。由于隔离了不同帐户可执行的 *** 作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。

3、用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。用参数化查询，这样语句就变为Sql="Select * from 用户表 where 姓名 = @Name and 密码 = @Pass,这样就杜绝'字符所造成的漏洞了。

4、限制输入的长度。

5、将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。

6、检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。

二、HTML语法漏洞

如果没有对用户发言作出HTML语句过滤，就会让恶意破坏的用户利用html写出js攻击语句，典型的如不断开窗口直至死机，win9x死机等！

解决方法：

将HTML语句加密一下就行了，如：Server.HtmlEncode("用户发言")，也可直接过滤'<>这些HTML语法符号，如果想使用HTML语法的用户不妨用UBB语法代替！

一、Data SourceSqlConnectionStringBuilder的DataSource属性，对应connectionString中的Data Source，“Data Source”可以由下列字符串代替：“server”，“address”，“addr”和“network address”。Data Source=.\SQLExpress也可以写成这样Data Source=(local)\SQLExpress。

二、Integrated SecuritySqlConnectionStringBuilder的IntegratedSecurity属性，对应connectionString中的Integrated Security，“Integrated Security”可以写成“trusted_connection”，为true时，使用当前的 Windows 帐户凭据进行身份验证，为false时，需要在连接中指定用户 ID 和密码。

三、AttachDBFilenameSqlConnectionStringBuilder的AttachDBFilename属性，对应connectionString中的AttachDBFilename，“AttachDBFilename”可以写成“extended properties”，“initial file name”。AttachDbFileName属性指定连接打开的时候动态附加到服务器上的数据库文件的位置。这个属性可以接受数据库的完整路径和相对路径（例如使用|DataDirectory|语法），在运行时这个路径会被应用程序的App_Data目录所代替。

四、User InstanceSqlConnectionStringBuilder的UserInstance属性，对应connectionString中的User Instance ,该值指示是否将连接从默认的 SQL Server Express 实例重定向到在调用方帐户之下运行并且在运行时启动的实例。UserInstance=true，在这种情况下，SQLServerExpress为了把数据库附加到新的实例，建立一个新的进程，在打开连接的用户身份下运行。在ASP.NET应用程序中，这个用户是本地的ASPNET帐号或默认的NetworkService，这依赖于 *** 作系统。为了安全地附加非系统管理员帐号（例如ASP.NET帐号）提供的数据库文件，建立一个独立的SQLServer用户实例是必要的。

一，注入问题：

过滤页面跳转的特俗符号，单引号啊！双减号啊！还有检测是否存在关键字select、update之类的！传过来的参数先用一个string类型接受。然后合法以后在进行下一步 *** 作！然后你可以适用Parameters来执行数据库 *** 作！先定义数据类型！防止不发数据类型拼接SQL语句！

二，验证问题:

一定要适用客户端服务器双重验证！客户端验证人家可以修改！抓包什么的！还有欺骗！

三,错误信息：

定义错误页面.我测试站点的时候很多信息都是从错误信息里面发现的！有时候还能爆绝对路径等等。。！所以一定要定义application_error啊！就是错咯我都不让你看见！

好了，这几点就好了！服务器安全就不说了！因为你没问！不然我就答非所问了。。。。。。

---