昨天刚上线一个网站,今天数据库里就被注入脚本代码,真是郁闷,做的东西怎么这么不安全呢,高手们给点建议吧!

解决方案 »

  1.   

    常规的写法确实是防不胜防啊!!
    本人也碰到过,自vs2005后,
    本人数据访问层用强类型的DataSet后,再没发生被注入的情况!!
      

  2.   

    用textbox.maxlength限制长度还有就是验证码控件.防止一次性注册很多.因为如果他们不够长的话,就减少了贴入大量脚本的可能性。 
    防止用户输入过长的字符.textbox.maxlength(). 
    限制错误信息给出的提示比如捕获到异常时,
    只显示一些通用的信息比如"数据源错误",而不是显示"exception.message"的信息,它可能会暴露出你系统的攻击点. 
    还有就是要小心的去掉特殊字符. 
    可以将单引号替换为2个单引号. 
    还有就是使用参数化命令啊,用存储过程执行转换来防止啊 
    限制用户访问数据库的帐号的权限啊. 
      

  3.   

    接分
    txthouseNo.Text.Replace("'", "")
    把文本框里的单引号替换成 空格
      

  4.   

      1.对于动态构造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命令。  2. 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外,它还使得数据库权限可以限制到只允许特定的存储过程执行,所有的用户输入必须遵从被调用的存储过程的安全上下文,这样就很难再发生注入式攻击了。  3. 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符,那么不要认可表单中输入的10个以上的字符,这将大大增加攻击者在SQL命令中插入有害代码的难度。  4. 检查用户输入的合法性,确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证,是为了弥补客户端验证机制脆弱的安全性。  在客户端,攻击者完全有可能获得网页的源代码,修改验证合法性的脚本(或者直接删除脚本),然后将非法内容通过修改后的表单提交给服务器。因此,要保证验证操作确实已经执行,唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象,例如RegularExpressionValidator,它们能够自动生成验证用的客户端脚本,当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象,你可以通过CustomValidator自己创建一个。  5. 将用户登录名称、密码等数据加密保存。加密用户输入的数据,然后再将它与数据库中保存的数据比较,这相当于对用户输入的数据进行了“消毒”处理,用户输入的数据不再对数据库有任何特殊的意义,从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile,非常适合于对输入数据进行消毒处理。  6. 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录,但实际返回的记录却超过一行,那就当作出错处理
      

  5.   

    1、注意代码防止sql注入。
    2、注意上传组件被盗用。
    3、注意数据库最高权限不要给程序,比如删除数据库。
      

  6.   

    1 .参数化
    2  使用orm框架等
    3  最简单的,看一下IIS日志
      

  7.   

    在global里做防SQL注入,操作数据库用存储过程
    参考
      

  8.   

    从安全性来考虑。避免sql注入。
      

  9.   

    怎么总是看到人发帖子说被人SQL注入莫非真的这么恐怖? SQL语句用拼接的方法看来挺恐怖?
      

  10.   

    public static bool updateAdmin(DataRow newAdminInfo)
        {
            string sql = @"update AdminGroups set big_id=@big_id,admin_id=@admin_id where [id]=@id ";
            SqlParameter[] Parms = {
                new SqlParameter("@id", SqlDbType.Int),
                new SqlParameter("@big_id", SqlDbType.VarChar),
                new SqlParameter("@admin_id", SqlDbType.Int),
            };
            Parms[0].Value = newAdminInfo[0];
            Parms[1].Value = newAdminInfo[1];
            Parms[2].Value = newAdminInfo[2];
            int i = SQLHelper.ExecuteNonQuery(sql, Parms);
            return i > 0 ? true : false;
        }
      

  11.   

    那说明这个网站的安全性不是很高,你可以将他改成成员角色管理,再配上三层架构和sql server的数据库,这样的话安全性会高一些的。
      

  12.   

    防止sql注入写存储过程.
    [id]=@id 
    this.textbox.text.trim();
    这些都是防止的。
    cookies也要少用其所长
      

  13.   

    提供一个简单的方法:过滤敏感字符
    由于恶意攻击者需要在输入框总输入的文本一般是含有"or”,"and”,"select","update","insert"等等之类的字符串片段,所以在拼接SQL之前先检查该用户提交的文本中是否含有这些敏感字符串,如果含有则终止操作。
      

  14.   

    JF,程序和SQL语句都要注意一下哦