如何使用vc6.0和sql2000进行连接和数据库 *** 作（查询插入更新删除），最好举例

快速删除留言板上的所有留言详细 *** 作步骤如下：
第一步：请登录QQ空间，点击留言板=》批量管理;
第二步：选择留言板中需要删除的留言，再点击“删除选中的”，最后“确定”删除即可。
注：点击“全选”后一次性最多可删除10条留言。

ASPNET如何防止SQL注入

一、什么是SQL注入式攻击

所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造(或者影响)动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：

⑴ 某个ASPNET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。

⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASPNET应用构造查询的一个例子：

SystemTextStringBuilder query = new SystemTextStringBuilder(”select from Users where login = ’”)。Append(txtLoginText)。Append(”’ AND password=’”)。Append(txtPasswordText)。Append(”’”);

⑶ 攻击者在用户名字和密码输入框中输入”’或’1’=’1″之类的内容。

⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASPNET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的 SQL命令变成：select from Users where login = ’’ or ’1’=’1’ AND password = ’’ or ’1’=’1’

⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。

⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。

如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。

系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的 *** 作，包括添加、删除或更新数据，甚至可能直接删除表。

二、如何防范

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

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

第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，”select from Users where login = ’’’ or ’’1’’=’’1’ AND password = ’’’ or ’’1’’=’’1’”显然会得到与”select from Users where login = ’’ or ’1’=’1’ AND password = ’’ or ’1’=’1’”不同的结果。

第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如”select from Users where login = ’mas’ —— AND password =’’”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。

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

⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。

⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。

⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本(或者直接删除脚本)，然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证 *** 作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如 RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。

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

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

;

一 什么是SQL注入式攻击         所谓SQL注入式攻击 就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串 欺骗服务器执行恶意的SQL命令 在某些表单中 用户输入的内容直接用来构造（或者影响）动态SQL命令 或作为存储过程的输入参数 这类表单特别容易受到SQL注入式攻击 常见的SQL注入式攻击过程类如         ⑴ 某个ASP NET Web应用有一个登录页面 这个登录页面控制着用户是否有权访问应用 它要求用户输入一个名称和密码         ⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令 或者直接用作存储过程的参数 下面是ASP NET应用构造查询的一个例子         System Text StringBuilder        query = new System Text StringBuilder（        SELECT from Users WHERE login = ）        Append（txtLogin Text）        Append（ AND password= ）        Append（txtPassword Text） Append（ ） ⑶ 攻击者在用户名字和密码输入框中输入 或 = 之类的内容         ⑷ 用户输入的内容提交给服务器之后 服务器运行上面的ASP NET代码构造出查询用户的SQL命令 但由于攻击者输入的内容非常特殊 所以最后得到的SQL命令变成         SELECT from Users WHERE        login = or = AND        password = or =         ⑸ 服务器执行查询或存储过程 将用户输入的身份信息和服务器中保存的身份信息进行对比         ⑹ 由于SQL命令实际上已被注入式攻击修改 已经不能真正验证用户身份 所以系统会错误地授权给攻击者         如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询 他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能 欺骗系统授予访问权限         系统环境不同 攻击者可能造成的损害也不同 这主要由应用访问数据库的安全权限决定 如果用户的帐户具有管理员或其他比较高级的权限 攻击者就可能对数据库的表执行各种他想要做的 *** 作 包括添加 删除或更新数据 甚至可能直接删除表     二 如何防范         好在要防止ASP NET应用被SQL注入式攻击闯入并不是一件特别困难的事情 只要在利用表单输入的内容构造SQL命令之前 把所有输入内容过滤一番就可以了 过滤输入内容可以按多种方式进行

        ⑴ 对于动态构造SQL查询的场合 可以使用下面的技术         第一 替换单引号 即把所有单独出现的单引号改成两个单引号 防止攻击者修改SQL命令的含义 再来看前面的例子 SELECT from Users WHERE login = or = AND password = or = 显然会得到与 SELECT from Users WHERE login = or = AND password = or = 不同的结果         第二 删除用户输入内容中的所有连字符 防止攻击者构造出类如 SELECT from Users WHERE login = mas AND password = 之类的查询 因为这类查询的后半部分已经被注释掉 不再有效 攻击者只要知道一个合法的用户登录名称 根本不需要知道用户的密码就可以顺利获得访问权限         第三 对于用来执行查询的数据库帐户 限制其权限 用不同的用户帐户执行查询 插入 更新 删除 *** 作 由于隔离了不同帐户可执行的 *** 作 因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT UPDATE或DELETE命令         ⑵ 用存储过程来执行所有的查询 SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击 此外 它还使得数据库权限可以限制到只允许特定的存储过程执行 所有的用户输入必须遵从被调用的存储过程的安全上下文 这样就很难再发生注入式攻击了         ⑶ 限制表单或查询字符串输入的长度 如果用户的登录名字最多只有 个字符 那么不要认可表单中输入的 个以上的字符 这将大大增加攻击者在SQL命令中插入有害代码的难度         ⑷ 检查用户输入的合法性 确信输入的内容只包含合法的数据 数据检查应当在客户端和服务器端都执行 之所以要执行服务器端验证 是为了弥补客户端验证机制脆弱的安全性         在客户端 攻击者完全有可能获得网页的源代码 修改验证合法性的脚本（或者直接删除脚本） 然后将非法内容通过修改后的表单提交给服务器 因此 要保证验证 *** 作确实已经执行 唯一的办法就是在服务器端也执行验证         你可以使用许多内建的验证对象 例如RegularExpressionValidator 它们能够自动生成验证用的客户端脚本 当然你也可以插入服务器端的方法调用 如果找不到现成的验证对象 你可以通过CustomValidator自己创建一个         ⑸ 将用户登录名称 密码等数据加密保存 加密用户输入的数据 然后再将它与数据库中保存的数据比较 这相当于对用户输入的数据进行了 消毒 处理 用户输入的数据不再对数据库有任何特殊的意义 从而也就防止了攻击者注入SQL命令 System Web Security FormsAuthentication类有一个HashPasswordForStoringInConfigFile 非常适合于对输入数据进行消毒处理         ⑹ 检查提取数据的查询所返回的记录数量 如果程序只要求返回一个记录 但实际返回的记录却超过一行 那就当作出错处理    

    以上资料参考与 赛迪网资料   但是我觉得在我们的ASP NET程序里防止SQL 注入        首先应该尽量使用存储过程 关于使用存储过程的好处在这里就不展开讨论了        使用参数传递变量         最不妥当的方法就是认为判断SQL注入信息         尽管如此 可能日常开发中由于种种原因不能做的面面具道 存在各种各种的实际问题 现在是最近在一个项目中没有考虑SQL注入项目补救写的一个组件库 资料也参考来源与网络 实现很简单 下面是具体实现的源程序         using System;        using System Text RegularExpressions;        using System Web;        namespace FSqlKeyWord        …{        ///// <summary>        /// SqlKey 的摘要说明         /// </summary>        public class SqlKey        …{        private >