防止sql注入代码怎么写( 四 )


测试字符串变量的内容,只接受所需的值 。拒绝包含二进制数据、转义序列和注释字符的输入内容 。
这有助于防止脚本注入,防止某些缓冲区溢出攻击 。测试用户输入内容的大小和数据类型,强制执行适当的限制与转换 。
这即有助于防止有意造成的缓冲区溢出,对于防治注入式攻击有比较明显的效果 。如可以使用存储过程来验证用户的输入 。
利用存储过程可以实现对用户输入变量的过滤,如拒绝一些特殊的符号 。如以上那个恶意代码中,只要存储过程把那个分号过滤掉,那么这个恶意代码也就没有用武之地了 。
在执行SQL语句之前,可以通过数据库的存储过程,来拒绝接纳一些特殊的符号 。在不影响数据库应用的前提下,应该让数据库拒绝包含以下字符的输入 。
如分号分隔符,它是SQL注入式攻击的主要帮凶 。如注释分隔符 。
注释只有在数据设计的时候用的到 。一般用户的查询语句中没有必要注释的内容,故可以直接把他拒绝掉,通常情况下这么做不会发生意外损失 。
把以上这些特殊符号拒绝掉,那么即使在SQL语句中嵌入了恶意代码,他们也将毫无作为 。多层环境如何防治SQL注入式攻击? 在多层应用环境中,用户输入的所有数据都应该在验证之后才能被允许进入到可信区域 。
未通过验证过程的数据应被数据库拒绝,并向上一层返回一个错误信息 。实现多层验证 。
对无目的的恶意用户采取的预防措施,对坚定的攻击者可能无效 。更好的做法是在用户界面和所有跨信任边界的后续点上验证输入 。
如在客户端应用程序中验证数据可以防止简单的脚本注入 。但是,如果下一层认为其输入已通过验证,则任何可以绕过客户端的恶意用户就可以不受限制地访问系统 。
故对于多层应用环境,在防止注入式攻击的时候,需要各层一起努力,在客户端与数据库端都要采用相应的措施来防治SQL语句的注入式攻击 。
7.怎么样防止Sql注入(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命令 。
⑵ 用存储过程来执行所有的查询 。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击 。此外,它还使得数据库权限可以限制到只允许特定的存储过程执行,所有的用户输入必须遵从被调用的存储过程的安全上下文,这样就很难再发生注入式攻击了 。
⑶ 限制表单或查询字符串输入的长度 。如果用户的登录名字最多只有10个字符,那么不要认可表单中输入的10个以上的字符,这将大大增加攻击者在SQL命令中插入有害代码的难度 。
⑷ 检查用户输入的合法性,确信输入的内容只包含合法的数据 。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证,是为了弥补客户端验证机制脆弱的安全性 。