为什么说参数化只能一定程度上防止SQL注入呢

即使某些人在文本框输入了drop table ***之类的语句，也是当做文本提交到数据库了啊，没有造成任何危害啊如果说有点危害我是觉得，如果输入了什么<div style="center"></div>再加些格式之类的，又比如<iframe>的有些危害，有的话审核的时候删掉就OK乐，可是数据库方面没有被破坏啊为什么说只是一定程度上防止了SQL的注入呢达人解释一下吧

解决方案 »

  1.   

    呵呵，你还是在网上搜索下sql注入吧，看你对这还不了解。
    关于sql注入的介绍挺多的
      

  2.   

    当然一定程度上防止sql注入了啊！如果你通过url 中参数1=a&参数2=b这在一定程度上就加大sql注入的可能
      

  3.   

    楼主 看看这个http://topic.csdn.net/u/20081205/09/3dd06076-bcbe-45d4-998c-8999fdbe6fae.html我只摘掉参数化防注入已经相当不错了，但是没有100%的事情
      

  4.   

    个人意见：
    参数化可以完全防止SQL注入到目前为止，我还没有看到参数化之后被注入的例子
    大家都说一定程度上，是怕万一被注入了，还有后退的余地
    我认为是一种不负责任的做法
    技术上的事情，不要用可能，很大程度上之类来形容，有就是有，没有就是没有凡是认为参数化不能完全防止SQL注入的，写出代码示例和实际注入过程
    所谓有图有真相，完全靠猜测说能不能注入，说可能性是不是会增大之类，没有任何意义
      

  5.   


    呵呵，请问用存储过程和用SQL 参数化 只从安全性方面考虑，是不是一样的呢
      

  6.   


    不一样
    用存储过程，如果在存储过程的代码里，还是采用SQL拼接的方式构造SQL语句，照样会引起注入问题
      

  7.   

    拼接？你说的是这种格式
    "update table set aa="+aa;
    我说的是这种，只要有参数就用这样的格式
    sqlparameter ****
    "update table set aa=@aa"
    这样写SQL语句，和用存储过程是一样的吗？只从安全方面？
      

  8.   

    这就要你去看一下SqlParameter是怎样防止SQL注入的。
    如果它有自己的编码方式，那可以构造和SqlParameter一样的编码方式进行注入SQL
      

  9.   

    参数化应该可以完全防止SQL注入，但计算机上这些东西，谁也不敢说100%
      

  10.   


    不管你怎么写，关键在于参数
    你写了存储过程updateXXX，如果调用的时候传递进去的参数仍然采用 SQL = "Exec updateXXX " + aa;
    这样的方式，那仍然是有注入危险的。参数化和写存储过程防止注入，根本就是两回事
    网上很多东西，需要你自己动脑经去想，动手去实践
      

  11.   

    我个人觉得中规中矩的参数化，最后生成的sql只要不是动态拼接的，都可以防止注入。
    就如sql="select * from user where name=@name" (@name由用户输入的)，这样注入不了。
    如果说最后生成的sql只要是动态拼接的，都可以被注入。
    就如sql="select * from user @where" (@where="name='"+name+"'"，这里的变量name由用户输入的)，这个写法虽然也用了参数化，但是还是可以被注入，这样的sql就等于sql="select * from user  where name='"+name+"'"一样的，肯定能被注入。其实这时只要把name替换1个单引号成2个单引号就可以防止注入了，我一般name=name.Replace("'","''");人家还说还要过滤其他关键字，其实没必要，其他关键字之所以能威胁数据库，是因为先破了单引号，只有在这之后关键字才起作用。只要把1个单引号成2个单引号后，这些关键字就没效果了。所以说不管是存储过程带参数还是sql带参数，只要最后执行的sql是动态拼接的话，还是可能被注入的。
      

  12.   

    不用Exec，执行拼接字符串就没有注入问题。